Телеграм канал «Наташа Косинова. Варю айти СУП»

🎤Ура! Прямой эфир!
Очень давно не проводила прямых эфиров, а пообщаться с умными людьми очень хочется)

На этот раз я пригласила Татьяну Бунто!

Татьяна прошла путь от аналитика, была РП, аккаунтом, продактом, директором по развитию продукта, а сейчас занимается развитием новое направления в компании HFLabs.

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

Основные темы нашего прямого эфира это:‼️
1. Осмысленный подход и вопрос ЗАЧЕМ?
2. Обратная связь, как её просить, возвращать и где есть свои "подводные камни".

Если у вас есть вопросы к Татьяне, пишите под этим постом👇 мы их обязательно обсудим!

Ждём вас на прямом эфире уже завтра
✔️05 февраля с 17:30 по Москве (сохраняйте ссылку на встречу в zoom https://us06web.zoom.us/j/82845763864?pwd=yU06f1z41wtbQOWcnZY1gaO1Svc2ru.1 ).
Планируйте своё время))

Запись будет 😎

‼️Расписание на февраль

✔️5 февраля - (чт) прямой эфир с Таней Бунто, будем говорить про вечный вопрос "Зачем?" Разбираться в том, почему аналитики не задают ключевой вопрос зачем.
Разговор состоится с 17:30 до 18:30 по Москве, ссылку на зум отправлю тут заранее. Участие открытое.

✔️9, 11, 13 февраля (пн, ср, пят) бизнес-игра, онлайн тренинг "Китайская ручка" вечера с 19:00 до 21:30 по Москве. Заявку на участие можно оставить на сайте.

✔️17 февраля (вт) - мастер-класс по онтологическому моделированию предметной области с 18:30 до 21:30 по Москве.
Чтобы принять участие, пишите мне в личку слово - онтология!

✔️28 февраля, 1 марта (суб, вск) - бизнес-игра, онлайн тренинг "Большая стирка" с 10:00 до 14:00 по Москве. Заявку на участие можно оставить на сайте.

Проверка полноты требований
| Про требования §5 из 14

Долгое время я не любила user story. Мне казалось, что это какая фигня. Очень поверхностные хотелки. Но самое главное, что мне не нравилось в user story, это как мне казалось, невозможность увидеть границы и полноту, того, что мы должны разработать.

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

А инструмент user story map, везде преподносился как инструмент планирования и определения mvp, релизов.

И что я делала?
Чтобы увидеть системную картину, и поработать с полнотой требований, границам проекта, я добавляла набор use cases. Через сценарии довыявляла масштаб бедствия.

Полноту требований можно обеспечить разными способами. И если бы говорим про user story, один из вариантов это использовать user story map.

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

Хотите попрактиковаться в подобных задачах?
Приходите на тренинг по основам разработки требований "Китайская ручка"
Даты тренинга 9, 11, 13 февраля, вечерами по московскому времени.
Оставить заявку на участие можно на сайте.

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

А как вы работаете с полнотой требований? 🤔

Сегодня расскажу про аэродинамическую трубу в ЦАГИ. Я люблю посещать научные, промышленные, инженерные экскурсии. Потому что часто работа инженеров, проектировщиков, настолько же интересна и важна, как и работа архитектора. Внутреннее устройство бывает даже интереснее внешнего, хотя его и не видно. Плюс такие мероприятия мне дают энергию.

ЦАГИ, в качестве эксперимента решили к столетию аэродинамической трубы провести экскурсию. Я долго не думала и решила, что надо идти.
Немного истории
31 декабря 1925 в ночь на 1 января 1926 на улице Радио в Москве заработала аэро труба. А точнее даже две в одной, под кодами Т-1, Т-2. 1925 год, зима, не самое удачное время со всех сторон, но было принято решение делать аэро трубу. Она была необходима для экспериментов.
Было холодно, и пока строили бегали греться в дом, где работал Жуковский и там был камин. Кстати, музей Жуковского заслуживает внимания, много экспонатов и можно погрузиться в историю Авиации и Космонавтики.

История про ЦАГИ интересна тем, что Жуковский, Чаплыгин работали в Бауманке, что располагается рядом. И конечно же общались с факультетом архитектуры, там же. Так что проблем с проектированием не было. Проект делал молодой архитектор Кузнецов. Вся труба сделана из дерева. Из сосны и собрана так, что сосна по росту волокон расположена. Не трескается. За 100 лет не меняли ничего. Экспертиза даже особых отклонений не обнаружила. Балки между собой на стыках винтами закреплены, которые можно подтягивать или расслаблять. Собирали трубу и балки вокруг трубы - 12 человек.

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

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

Самые забавные чувства, это когда заходишь во внутрь, потому что эта труба, как машина времени. Вокруг всё так как было, и оборудование тоже аналоговое) Открыл дверь и 100 лет куда-то улетело 😂

Эта труба работает до сих пор. ЦАГИ получает много разных заказов. Например, современные здания Москва Сити, памятник во Ржеве, колесо обозрения Солнце Москвы и др. Из того, что было в истории: памятник рабочий и колхозница, Веру Мухину просили убрать шарф у колхозницы, но Мухина не согласилась, тогда бы нарушили композицию. И было принято решение внутри поместить гаситель вибрации (или что-то типа).
Ещё более дальняя история заказов - это московский эподром делал заказ на обдувку лошадей и понимание нагрузок на лошадь с повозкой, без, с всадником, без. Конечно ворону и других пернатых изучали, они же летают, и их крылья созданы идеально.

И есть история, что на запрос обдувки петуха Чаплыгин запретил такие работы сказал, что петух не летает!)

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

Фотографии, что публикую, разрешены и переданы сотрудником ЦАГИ.

Почему у аналитиков проблемы с требованиями?
| Про требования §4 из 14

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

Сегодня расскажу почему так происходит?
И что я замечаю на занятиях, почему базовая компетенция страдает?

✅1.Обесценивание. Ну это же просто, поэтому можно подойти к делу также без внимания, спустя рукава. Если я умею писать, то автоматически умею писать требования, примерно так рассуждают. Что греха таить, я сама долгое время считала, что всё понятно с требованиями, почему снова и снова ведутся разговоры)
✅2.Не понимание сути работы с требованиями. Вот все твердят, спрашивают, просят читать Вигерса. Но аналитик может просто не понимать, что от него требуется. Это как в школе, сказали делить на ноль нельзя, но никто не объяснил почему, просто запретили спрашивать. И вот мучаешься, но живёшь с этой мыслью. А потом, внезапно оказывается, что можно!!! Настолько нас били по рукам, (я про себя тут говорю), что задавать вопросы, или ковыряться в задание не будешь. Дали задачу, понял, не понял, надо делать.
✅3.Банально, но хромают русский язык и логика. Может конечно тут ИИ поможет, как та же автопроверка слов. По крайней мере в формулировках. А вот понять, что требование из себя представляет высказывание, которое в любой момент может быть истинно или ложно, тут уже сложнее. Как раз то самое непротиворечие, логичное по структуре, завершенное. А то такие бывают требования, что одна часть отменяет другую часть...
✅4.Пытаются впихнуть всё, чтобы ничего не забыть. В итоге расширяют себе область анализа до бесконечности и сами себя зарывают. Таким полем сложно управлять.
✅5.Не видят картину целиком. Набор требований - это система. И одно может быть связано с другим.
✅6.Не проверяют свои требования на качество. Вроде бы все знают атрибуты качества требований, но не применяют на практике. А по идеи такая проверка должна быть понаитию встроена в нас.
✅7.Сложно понимать абстракции и работать на разных уровнях, этих самых абстракций. Да, буду постоянно это повторять. Потому что, без классификации требований сложно ими управлять. А если нельзя потрогать, то надо представлять, моделировать, структурировать, подбирать разные инструменты, подходы.

Что делать?
Практиковаться, и теорию применять на практике.
#капитаночевидность

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

Хотите попрактиковаться?
Приходите на тренинг по разработке требований - Китайская ручка)

‼️Набираю открытый поток тренинга, занятия вечерами в будние 9, 11, 13 февраля.

➕Почитать подробнее и оставить заявку можно на сайте.

----------
Предыдущие посты по теме.
1. С чего начинать проектирование?
2. Спецификация не фантазия на тему. Что поможет в формирование?
3. Требование VS решение

Требование VS Решение
| Про требования §3 из 14

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

Чтобы качество требований было выше - описывайте требования, а не решение.

Пример из жизни.
Нужно добраться из Москвы в Петербург.
Что проще может быть. Но тут важен контекст и условия задачи. Кто, в какие сроки поедет, какие есть ограничения финансовые, может по здоровью, документы, сопровождение и т.д. Да и вообще сейчас снежная зима. А может у нас едет группа детей, и вот они новые условия. Варианты решения - поезд, сапсан, самолёт, автобус, велосипед, лыжи, лошадь, пешком.
Если мы сразу напишем решение, потому что всегда так делали. Откуда оно взялось и почему мы приняли такое решение, уже никто не вспомнит. Ничего не напоминает?)

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

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

✅ Явные признаки решения - оно может быть разным, и его никто не просил в таком виде, в котором вы его описали. То есть можно поменять и ничего не развалится.
Поедем в Питер на машине)))

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

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

А вы чаще, что пишите? Требования или решения?

----------
Предыдущие посты по теме.
1. С чего начинать проектирование?
2. Спецификация не фантазия на тему. Что поможет в формирование?

Спецификация требований - это не фэнтези, не свободное сочинение на тему.
| Про требования §2 из 14

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

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

И вот аналитик спросил пару раз у заказчика что собственно надо. Вроде понял и побежал сразу делать. Что-то изучать, для слабаков, ведь понятно какая задача стоит, с аналитика требуют ТЗ!

Что делать?
✅Вводить классификацию требований, хотя бы как Вигерс завещал. Понимать, где у нас бизнес уровень, где пользовательский, функциональный, системный и конечно не забыть про нефункциональные требования.

✅Выдерживать один контекст обсуждения с заказчиком. А то получается "сломанный телефон", заказчик нам говорит - у меня проблема на складе, воруют, а мы в ответ - купите у нас систему баг-треккинга, вангую она вам сейчас нужна. Как вам её настроить?

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

Ну сказали написать ТЗ, вот и пишу, че ещё надо. Всё что говорит заказчик фиксирую.

И вот мы в ТЗ получаем машину времени или телепорт. Почему? Откуда? Непонятно. ТЗ написано и ушло в разработку, а фарш уже прокрутить назад невозможно.

✅Начинайте с бизнес потребности. Насколько она реальная, валидируйте бизнес цели с командой. Всё таки проект сложное мероприятие, поэтому и делает проект команда!

И произносите мантру:
Проваливаясь на системный уровень требований, я в разы понижаю качество ТЗ.

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

Завтра расскажу на примерах, чем требование отличается от решения!

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

А пока делитесь мыслями, как обстоят у вас дела с требованиями? Отдали написание ТЗ помощнику ИИ? 🥸

----------
Предыдущие посты по теме.
1. С чего начинать проектирование?