Число подписчиков канала перевалило за 5000! Спасибо вам! 🙏🏻

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

Не переключайтесь, у меня есть ещё много идей. Когда-то давно я был на конференции АИСТ, и в одном из докладов ребята рассказывали, как пытались проанализировать — чем отличаются посты популярных блогеров? Оказалось, что нельзя выделить какие-то общие критерии: ни особые темы, ни длину сообщений, ни употребляемые слова, ни наличие картинок в посте... Кроме одного — частоту постов. Когда я начинал вести канал, мне казалось, что писать-то особо не о чем. А сейчас я пишу посты почти каждый день, и темы для них не заканчиваются! Это удивительно и для меня самого, а вам, надеюсь, интересно.

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

Ну а в честь такого круглого числа хочу сделать вам подарок: я знаю, у многих есть свои каналы — напишите про них в комментариях к этому посту, а про самые интересные каналы я напишу отдельным постом со своими комментариями. Пусть и у вас будет праздник!

На ЛАФ рассказывал про историю UML, про его взлеты и падения, и совсем чуть-чуть про исследование его актуальности.

На Flow буду рассказывать прицельно про результаты: https://flowconf.ru/talks/5a9403b9ba8c43609a30da8eab1897d2/

Уже можно сказать, что результаты расходятся с немецкими исследованиями 2014 и 2017 годов: в 2024 в РФ аналитики используют UML чаще; почти всегда рисуют формальные диаграммы;  используют Use Case Diagram чаще, чем Class Diagram и всегда сохраняют созданные диаграммы для будущего использования или документации.

Не собираюсь в этом году как-то сильно поражать воображение слушателей, на мой взгляд, в программе есть много гораздо более сильных докладов. Честно говоря, работа в ПК оказывается довольно тяжёлой, даже не представляю, как справляются люди, которые в трёх конференциях в программных комитетах — это же как ещё одна работа!

В общем, встречаемся в Питере и в онлайне. Многим из вас, наверное, участие оплатит компания, ну а те, кто едет сам — пишите мне в личку, выдам промокод на скидку 25%! 🎫

Тут в одном чате аналитиков с удивлением прочитал вопрос: аналитики, а вы занимаетесь сбором и фиксацией требований? От человека, который не очень давно аналитиком работает, на курсах его сбору требований учили, но на практике это ему не нужно.

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

Кто-то с гордостью(!) говорит, что ни требований никогда в глаза не видел, ни диаграмм никаких не рисовал никогда.

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

Поэтому опрос (следующим постом): а чем вы в повседневной работе занимаетесь?

Интересно — на первом месте ответ "Пишу документацию". Сформулировано, конечно, максимально общо, а что вы под этим подразумеваете?

На мой взгляд, документация — это когда уже зафиксированы решения, а может даже всё уже сделано. И тут возникает, мне кажется, ключевой вопрос: вы фиксируете в документации решения, принятые вами, или кем-то другим (тогда кем, что это за роль?).

И если другими — ваша задача просто зафиксировать/описать решения, или же так организовать всех, чтобы нужные решения были приняты, и приняты с учетом всех аспектов, нюансов и последствий? Я и в своей работе, и в процессе менторинга/консультаций постоянно встречаюсь с этой задачей аналитика: организовать пространство и процесс принятия решений. Всех собрать, всем дать полную картину (или нужные им части, например, по безопасности, НФТ или изменению нормативки), организовать процесс.

Кажется, это тоже невидимая работа (а работа эта непростая!), о которой молчат на курсах и которую не замечают и не ценят руководители. "Ну ты собери совещание, и всё решите там". Угу, чего там говорить, само всё произойдет.

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

Например, я давно читаю канал Тиграна Басеяна Black Product Owner.

Материала там — хватит на целый курс по управлению продуктом. Вот, например, пост с разными картами компетенций продакта и инструментами их оценки.

А вот — серия постов про юнит-экономику простыми словами.

Или вот модель оценки зрелости продуктового управления — даже если вы не продакт, замените "управление продуктом" на "системный анализ", и оцените зрелость своей компании.

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

В общем, рекомендую! Подписывайтесь, если тема управления продуктами вам интересна!

https://news.1rj.ru/str/blackproduct

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

* Customer Development Inrerview. Совсем не то же самое, что интервью с пользователем по выяснению деталей бизнес-процесса и сбору требований. Тут вы обычно говорите с людьми, которым вообще ничего не надо, либо надо что-то совсем другое, либо они поддержат любую вашу идею, просто потому, что они хорошо к вам относятся. Главное отличие тут — ничего не спрашивать про продукт и вообще не говорить о нем. Классическая книга — “Спроси маму” Роба Фитцпатрика (она и аналитикам полезна).

* UX, а особенно — два аспекта: 1) что происходит в голове у пользователя, какая у него ментальная модель и какие чувства, и 2) тексты в интерфейсах. На удивление, это серая зона — тексты в интерфейсах не умеют писать ни дизайнеры, ни копирайтеры, ни уж тем более аналитики. Вообще это отдельная специальность — UX-редактор, но в РФ её практически нет. Тут могу порекомендовать Иру Моторину, её канал — https://news.1rj.ru/str/redachredach

* Legal Compliance & Ethics. Соблюдение регуляторных требований и этика. Сюда же — безопасность и защита пользовательских данных. Не знаю, что здесь порекомендовать, если знаете что-то стоящее — напишите в комментах. Это про юридическую обвязку, пользовательские соглашения, перс. данные, куки и т.п. Про этику вообще никто ничего нигде не рассказывает, только в обсуждениях скандалов и можно пощупать тему. Кстати, в BABOK есть раздел "Этика", кто его читал/помнит?

* Поддержка пользователей / Customer Success. Тоже серая зона, но по моему опыту, часто попадает в ведение продакта (потому что больше никому не надо). В любом случае, взаимодействие со службой поддержки — кладезь продуктовых кейсов и инсайтов.

* Метрики и аналитика — тут понятно, и это очень связано с юнит-экономикой.

* Ценообразование. Какую цену на продукт вообще поставить? Тут много материалов из институтских курсов по экономике/маркетингу, но они мало помогают. В каждом конкретном случае всё индивидуально.

* Маркетинг в разных видах ("а чем ваш продакт вообще отличается от хорошего маркетолога?"), а особенно — контентный маркетинг. Ваш продукт (и вы сами) — медиа, действуйте соответственно. Я тут читаю Катю Макарову https://news.1rj.ru/str/everythingpersonal и Линор Горалик https://news.1rj.ru/str/thecontentisthequeen

* Стратегия. Черт его знает, что это, но заниматься в какой-то момент приходится. В общем, это про то, что мы делаем и зачем, а чего мы точно делать не будем. Мне тут нравится подход Бориса Вольфсона, про который он рассказывал на WAW, а я писал https://news.1rj.ru/str/systemswing/315

Ещё продакту, а особенно CPO, хорошо бы разбираться в корпоративном управлении и политике, потому что он отвечает за успех продукта, а перед кем он отвечает? Перед владельцем или владельцами, которых в стартапе обычно несколько. Но это уже тема отдельного разговора.

Когда говоришь о продуктовом подходе, у аналитиков бывает отторжение: ну, это про всякие магазины / приложения, а у нас — внутренняя автоматизация, нам это всё ни к чему. У нашего пользователя нет выбора — использовать наш продукт или не использовать. На ЛАФ была отличная заявка на доклад про метрики внутренних продуктов, жаль, автор снял доклад. Надеюсь, ещё где-нибудь расскажет.

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

Вот метрика удовлетворенности как раз может быть очень важна для внутренних продуктов: да, работники обязаны пользоваться вашей системой, но при её использовании они мучаются или кайфуют? Как мы знаем, есть классические метрики NPS (Net Promoter Score) и CSAT/CSI (Customer Satisfaction Score/Index). Первую для внутренних продуктов применять немного бессмысленно ("Порекомендовали бы вы наш продукт своим друзьям?" — может и да, но как?). CSI лучше — поможет понять, как пользователь относится к вашей системе. Это такой опросник из двух частей: насколько вы удовлетворены каким-то аспектом работы системы (скоростью, удобством, поиском, созданием <чего-то> и т.п.)? И насколько важен для вас этот параметр?

Тут уже можно получить инсайты. Если в системе много пользователей, можно точечно спрашивать, насколько они удовлетворены конкретной функцией ("насколько вы довольны функцией поиска документа? Оцените по шкале от 1 до 5") — это CSAT. Так можно оценить каждую функцию отдельно. (Если пользователей у системы меньше 50 — проще с ними просто поговорить. Помним, что продуктовые методы начинают работать, когда мы физически не имеем возможности опросить каждого пользователя за разумное время).

Ещё для внутренних продуктов интересно спросить про усилия. Это будет CES — Customer Effort Score. Вопрос похож на CSAT, но немного другой: "насколько просто вам было найти документ? Оцените по шкале от 1 до 5, где 1 — очень сложно, а 5 — очень легко".

Но самая главная (на мой взгляд) метрика, говорящая об успешности системы, не имеет названия и мало где упоминается. Как одним вопросом понять, всё ли хорошо с вашим продуктом? Есть ли "product/market fit", за которым гоняются все стартаперы? Для них это вопрос выживания, для внутренних систем — вопрос капитала. Ваши пользователи — они за вас, или против?

Вот этот вопрос: "Что вы почувствуете, если больше не сможете пользоваться системой X?" С вариантами ответа: "Очень расстроюсь"; "Немного расстроюсь"; "Совсем не расстроюсь";

Простой вопрос, показывающий попадание системы в пользователя. Когда-то я сам набрел примерно на этот вопрос, но ответы были открытые, и звучали как "да я уже не представляю, как без этой системы работать", "это как третья рука", "а что, вы её только полгода назад запустили? Кажется, что я всегда в ней работал" — очень обнадеживает. Ну и можно косвенно судить по периодам планового отключения, когда нужно вернуться к альтернативам: "слава б-гу, наконец отключили это поделие", или "скорее включайте обратно, не можем без неё, это как в каменном веке!".

Я подсмотрел этот вопрос в статье создателя сервиса Superhuman, он описывает и референсные значения (40% и больше ответов "Очень расстроюсь" — у вас всё хорошо, более 60% — отлично), и следующие действия по улучшению показателя. И дополнительные вопросы:

1. Что вы почувствуете, если больше не сможете пользоваться системой?
2. Какие люди, как вам кажется, могут получить наибольшую пользу от системы?
3. Какую самую большую пользу вы получаете от использования системы?
4. Как мы можем улучшить систему для вас?

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

Сегодня расскажу про каналы своих подписчиков, как и обещал в посте про 5000. Каналы все классные!

Никита Харичкин ведёт канал Analyst Boost и сообщество по PlantUML. В канале — отчеты о конференциях, инсайты о работе аналитика и архитектора и полезные прихватки по работе с PlantUML. Вы, например, знали, что вместо activate/deactivate в диаграмме последовательности можно писать ++/--? Я вот тоже нет.

Дмитрий в канале DevFM пишет для Python разработчиков, но не только! Есть интересные посты про проведение ретро, про дизайн-документы от Google, про управление командой и коммуникации, а особенно мне понравились посты про всякие маааленькие нюансы: как лучше всего хранить в БД номера телефонов? Чем заменить cron, если нужно очень хитрое расписание? Какой тип данных выбрать для хранения строк — char, varchar или text? Обычные повседневные вопросы, которые оказываются не совсем простыми.

Канал "Пасека аналитика": жизнь и карьера аналитика, рефлексия опыта и безвозмездное менторство (!). Ловите момент.

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

Ещё один хардкорный канал: Лабораторные информационные менеджмент-системы и аккредитацию лабораторий. Метрология, стандарты, валидация ПО, управление качеством. Серьезные дела. Пошел читать ГОСТ ISO 17025.

Канал Валентина Заботина "Аналитик маминой подруги" — про работу и карьеру в системном анализе, а главное — про денюжки, деньгушечки, откровенно и честно. Всегда интересно.

Вот такие у меня классные подписчики! Желаю всем нам роста и успехов! И не стесняйтесь писать о себе и о том, что вам интересно!

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

Точнее, по трём параметрам:
1. Востребованность пользователями, это понятно.

2. Что нового мы сможем узнать? Это могут быть знания о поведении и предпочтениях пользователей или что-то о новой технологии.

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

И в бэклог спринта лучше всего брать задачи, продвигающие команду и заказчиков по всем трем признакам.

Взгляд на работу с требованиями с точки зрения дисциплины управления знаниями (knowledge managemant, KM) оказался очень любопытным, и объясняющим некоторые вещи. Я-то, так вышло, работал с методами KM, и даже был когда-то членом экспертного совета премии Most Admired Knowledge Enterprise Russia, так что с темой знаком. А вот для аналитиков и архитекторов, на удивление, эта тема малоизвестна. Хотя разговор про архитектуру систем всегда затрагивает вопросы управления знаниями, это у меня один из главный инсайтов с курса про микросервисную архитектуру. Закон Конвея и разделение по командам тоже про управление знаниями — какие знания аккумулировать в команде, а какие выдавать наружу.

С точки зрения системного анализа, KM тоже много где проявляется: это и сбор знаний со стейкхолдеров (специально не пишу "требований", потому что правильнее — знаний о предметной области и проблемах, которые мы собираемся решить), и передача знаний в команду (очень часто аналитика называют "единым источником информации о системе", "координатором знаний о системе", а при этом управлению знаниями-то и не учат!).

Например, такая вещь, как модель SECI (или модель Nonaka-Takeuchi) объясняет, что для разных стадий работы со знаниями нужные разные методы. Модель вводит различение между неявными знаниями (tacit knowledge, существует только в головах или в навыках людей и часто даже не осознается) и явными, эксплицитными (explicit knowledge, существует в виде отчужденного артефакта: документа, описания, регламента, записей). Если бы все знания были эксплицитными, и задачи разработки требований бы не было, точнее, она была бы сугубо технической.

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

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

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

И вот тут возникает интересная вещь — круг замыкается, и происходит интернализация, переход от эксплицитных знаний к неявным. Готовая система становится элементом среды, в которой действуют люди, и способ, которым они решают свои задачи при помощи системы, нигде не зафиксирован. И на следующем витке вновь возникает задача извлечения, экстернализации знаний о реальной практике использования системы. Процесс входит в цикл.

(Картинка из статьи Germán Scalzo и Guillermo Fariñas, лицензия CC BY 4.0)

Какая-то неделя рекомендаций каналов у меня получается. Вот тут ребята собрали папку каналов про agile, стратегию и системный анализ. Назвали, правда, «Гибкие технологии управления», но темы там шире. Всё про варианты развития аналитика: можно идти в организаторы процессов (читай — agile), можно в продакты или бизнес-партнеры, а там неизбежно придётся столкнуться со разработкой стратегии.

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

Добавляйте папку, читайте каналы, набирайтесь новых идей!

https://news.1rj.ru/str/addlist/pB26PWfXrAFkMWYy

В продолжение разговора о явных и неявных знаниях.

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

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

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

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

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

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

Понять, что знания неявные, очень просто: они не зафиксированы. Нет ни схем, ни регламентов, ни чеклистов, ничего. Как выполнять работу — передается из уст в уста, уровень зрелости процессов — 2, "фольклор" (первый уровень — "анархия", когда повторяемой деятельности вообще нет, нет процессов).

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

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

Меня зовут Юрий Куприянов. Я занимаюсь созданием ИТ-систем с 1998 года. Первые лет 10 работал программистом, тимлидом, архитектором систем. Где-то это был фриланс, где-то я работал в штате, занимался разработкой в разных областях: в медицине (одна из первых систем цифрового анализа ЭКГ), в нефтянке (писал софт для управления Ванинским НПЗ), в туризме (термина TravelTech тогда ещё не было), недвижке, hrTech, и т.д. Чуть было не написал одну из первых CMS, но один умный товарищ сказал — ну что ты ерундой занимаешься, какие-то там сайтики, иди нормальные вещи пиши на C++! До сих пор жалею.

Так получилось, что на всех проектах я выполнял роль аналитика, а зачастую и продакта — собирал требования, проводил обследования, писал ТЗ, когда было нужно, проектировал интерфейсы, пытался понять — что нужно пользователям. Вообще тогда не было такого сильного разделения труда — например, мы не знали о роли DevOps, а просто брали и выстраивали пайплайн релизов и миграций, анализировали нагрузку и администрировали сервера. Когда возникала задача поговорить с пользователями и выяснить, что им нужно, как-то так получалось, что шёл к ним разговаривать я. А если так не получалось, и шёл не я — на проекте начиналась твориться лютая дичь: например, мы только к концу разработки узнали, что система по подбору объектов недвижимости должна, оказывается, работать в киоске с тач-интерфейсом, а не на десктопе с мышкой.

Самым мощным проектом из тех времен было создание системы Казначейства Газпромбанка; она, кажется, работает уже 20 лет, хотя, конечно, морально и архитектурно ужасно устарела. Её вроде бы уже несколько лет переписывают много людей, не знаю, что там сейчас. Я был из тех самых 10x-еров, которые заменяют сразу 10 человек: мы написали всю систему буквально вдвоём + два стажера (они оба уже давно CTO крупных банков). Именно тогда я стал заниматься образованием и выпустил много отличных ребят — почти все сейчас либо основатели своих компаний (например, Флант), либо технические, либо дизайн-директора.

Потом я стал заниматься координацией работ в больших проектах, задачами анализа и проектирования корпоративной архитектуры. Возглавлял управление методологии, архитектуры и документации в Национальном расчетном депозитарии. Потом плюнул на корпоративный мир и занялся интернет-стартапом про онлайн-трансляции и видео-созвоны, когда про это ещё мало кто слышал (Zoom вышел в год нашего закрытия). Было весело: мы транслировали чемпионат России по спортивной гимнастике, первые интенсивы Бизнес-Молодости и концерты Московской Консерватории. Как обычно, всё сдохло из-за отсутствия маркетинга и присутствия флеша. Потом я занимался управлением знаниями, спроектировал систему управления идеями для Сбера, был экспертом премии MAKE Russia (Most Admired Knowledge Enterprise).

Параллельно я продолжал преподавать в МИЭМ, МФТИ, НИУ ВШЭ, в каком-то году был даже лучшим преподом Вышки по выбору студентов, и в 2015 эти интересы сошлись — я поучаствовал в запуске платформы "Открытое образование" — сначала написал начальное ТЗ, а потом руководил разработкой в роли директора по продуктам. Директор по продуктам я, правда специфический: больше про упихивание в срок невозможных проектов (openedu.ru запустили за 6 месяцев — от состояния "есть ТЗ и один Юра", до состояния "сплоченная команда внутренней разработки, три команды подрядчиков, курсы загружены на платформу, студенты начали регистрироваться") и про удовлетворенность пользователей (тот же openedu набрал полтора миллиона пользователей без маркетинга вообще). Так вышло, что с чисто коммерческими продуктами я мало работал. Хотя какое-то время дрючил разные проекты в заочке ФРИИ.

В общем, уже почти 10 лет я занимаюсь созданием систем в EdTech: Coreapp.ai, Университет 2035, в последний раз делал попытку привести в чувство Московскую электронную школу, но не очень преуспел в этом тяжком деле. Выгорел, собрал все шишки, временно ушёл "на пенсию".

Сейчас в основном консультирую, выступаю ментором и веду канал. Участвую в ПК конференций по системному анализу: Flow, ЛАФ, WAW. Сделал несколько топовых докладов (см. закреп). Первым написал про применение ChatGPT для задач аналитика, архитектора и продакта (сейчас Claude дает лучшие результаты). Провожу тренинги в школе Systems.Education. Соавтор книги "Цифровое качество" (к сожалению, пока что нет в продаже, что-то там с авторскими правами).

Что меня в основном интересует на сегодня: как же, всё-таки, мы создаём эти ИТ-системы и продукты? Как это всё происходит, и как должно происходить правильно, особенно в самом начале? Как разделить роли? Что должен делать разработчик, что архитектор, что продакт, что аналитик? Как устроен пресловутый SDLC? Работает ли agile? Как, блин, понять, что нужно этим пользователям и как им это дать?

Мои убеждения:

1. Требований объективно не существует. Тем более нельзя их "собрать", "выявить" или "извлечь". То, что мы называем требованиями — это высказывания о желаемом поведении системы, то есть, "собирая" требования — мы на самом деле изучаем деятельность людей и проектируем решение для поддержки этой деятельности, решения проблем в ней.

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

3. Если уж вы решили заниматься требованиями up front — я знаю много техник, которые позволят не пропустить важные требования и избежать недопонимания. Я про них часто рассказываю в канале.

4. Всё, что написано в книжках, нужно рассматривать скептически: умозрительные модели могут вообще никак не соответствовать реальной практике. Я верю в эмпирические исследования и стараюсь их изучать (и иногда пишу про них во второй канал: https://news.1rj.ru/str/yksdailylinks).

5. Любой стандарт или Body of Knowledge лучше книги: во-первых, там будет выжимка без воды, во-вторых — обычно стандарты всё же хоть как-то опираются на реальную практику, а не только на авторские идеи. К счастью, многие стандарты переведены и свободно доступны на русском языке.

Если у вас есть интерес в изучении того, как на самом деле устроен процесс создания систем в этом нашем ИТ, или вы знаете, где это изучают (обычно это какой-то университет) — рад буду познакомиться и что-то поделать вместе! А то у нас скептически относятся к независимым исследователям, нужно обязательно аффилироваться с какой-то организацией.