"В тексте обсуждается технический ассессмент системных аналитиков. Автор, который является преподавателем и директором по продуктам в школе, имеет опыт руководства системными аналитиками. Он представляет независимый центр оценки и обсуждает важность самооценки аналитиками, чтобы понять свое место на рынке труда. Текст обсуждает вопросы, которые могут возникнуть у аналитика при проведении такого ассессмента, включая вопросы о навыках, опыте, и целях. Он также подчеркивает, что маленьким компаниям может быть сложнее провести такую оценку из-за отсутствия сравнения с другими. Автор интересуется построением системы оценки, которая помогла бы аналитикам определить свое место и потенциал роста на рынке труда, а также как эта система может помочь внутри компании, включая развитие аналитиков и управление карьерным ростом."
"Во второй части текста обсуждаются дополнительные аспекты ассессмента системных аналитиков. Автор отмечает различия между аналитиками внутри больших компаний, где могут существовать разные подходы и системы оценки. Затем разговор переходит к рассмотрению того, как такой ассессмент может помочь аналитикам в общении с руководителями. Автор подчеркивает, что этот инструмент не только помогает аналитикам определить свое текущее место и цели развития, но также способствует более прозрачному общению между аналитиками и их руководителями. Он отмечает, что большие компании разрабатывают процессы оценки и карты компетенций, чтобы помочь аналитикам расти и развиваться на текущей позиции. Наконец, текст упоминает, как такой ассессмент может быть полезен при поиске работы и продвижении по карьерному пути."
"Во второй части текста обсуждаются дополнительные аспекты ассессмента системных аналитиков. Автор отмечает различия между аналитиками внутри больших компаний, где могут существовать разные подходы и системы оценки. Затем разговор переходит к рассмотрению того, как такой ассессмент может помочь аналитикам в общении с руководителями. Автор подчеркивает, что этот инструмент не только помогает аналитикам определить свое текущее место и цели развития, но также способствует более прозрачному общению между аналитиками и их руководителями. Он отмечает, что большие компании разрабатывают процессы оценки и карты компетенций, чтобы помочь аналитикам расти и развиваться на текущей позиции. Наконец, текст упоминает, как такой ассессмент может быть полезен при поиске работы и продвижении по карьерному пути."
❤3👍1
1. Главная идея заключается в важности технического ассессмента системных аналитиков для самооценки и определения их места на рынке труда.
2. Участники подчеркивают необходимость построения системы оценки и карты компетенций, которые помогли бы аналитикам определить свои навыки, цели развития и потенциал карьерного роста.
3. Ассессмент аналитиков также рассматривается как инструмент обеспечения более прозрачного общения между аналитиками и руководителями, а также как фактор, способствующий развитию на текущей позиции и продвижению по карьерному пути внутри компании.
4. Один из главных аспектов внутреннего ассессмента аналитика заключается в его нынешнем уровне компетенции и его развитии на текущей позиции внутри компании. Это позволяет руководителям и аналитикам прозрачно оценить его профессиональное развитие.
5. Внешний ассессмент, с другой стороны, более ориентирован на рынок и включает в себя сравнение навыков и компетенций аналитика с требованиями работодателей на рынке труда. Этот вид ассессмента позволяет аналитику понимать, какие навыки и тренды важны на текущем рынке.
6. Важно найти баланс между внутренним и внешним ассессментом, чтобы адекватно оценить свои навыки и понимать, куда стоит развиваться, как на текущей позиции, так и с точки зрения требований рынка труда.
В целом-то всё по делу распознал :)
2. Участники подчеркивают необходимость построения системы оценки и карты компетенций, которые помогли бы аналитикам определить свои навыки, цели развития и потенциал карьерного роста.
3. Ассессмент аналитиков также рассматривается как инструмент обеспечения более прозрачного общения между аналитиками и руководителями, а также как фактор, способствующий развитию на текущей позиции и продвижению по карьерному пути внутри компании.
4. Один из главных аспектов внутреннего ассессмента аналитика заключается в его нынешнем уровне компетенции и его развитии на текущей позиции внутри компании. Это позволяет руководителям и аналитикам прозрачно оценить его профессиональное развитие.
5. Внешний ассессмент, с другой стороны, более ориентирован на рынок и включает в себя сравнение навыков и компетенций аналитика с требованиями работодателей на рынке труда. Этот вид ассессмента позволяет аналитику понимать, какие навыки и тренды важны на текущем рынке.
6. Важно найти баланс между внутренним и внешним ассессментом, чтобы адекватно оценить свои навыки и понимать, куда стоит развиваться, как на текущей позиции, так и с точки зрения требований рынка труда.
В целом-то всё по делу распознал :)
👍10
Flow23-Kupriyanov.pdf
3 MB
Рассказал на Flow про скрытую работу по проектированию систем, которую выполняет системный аналитик. Хотя какая там скрытая! Вполне даже явная, в половине вакансий написано: проектировать интерфейсы пользователя, Figma; проектировать REST API, разрабатывать спецификацию в OpenAPI; знать Kafka и RabbitMQ, уметь на собеседовании объяснить разницу между AMQP и MQTT; знать SQL, уметь профилировать и оптимизировать запросы, разрабатывать физическую модель; уметь нарезать монолит на микросервисы. И аналитики такие: ЧТОА?
В общем, ловите презентацию, там есть немного ссылок по темам.
В общем, ловите презентацию, там есть немного ссылок по темам.
👍33❤10😁2🔥1
Forwarded from Максим Цепков (Maxim Tsepkov)
#flowconf Денис Бесков. Радикальное ускорение аналитических работ методикой Event Storming. Доклад из двух частей: проблемы классического подхода и Event Storming как метод решения этих проблем. Проблемная лично часть для меня - достаточно понятно и давно известна. Тем не менее, классические постановки по цепочке бизнес - модель бизнеса - требования - модель системы - система по-прежнему широко используются, потому что именно они положены в основу многих методологий. Именно поэтому фокусировка на этих проблемах - ценная часть доклада. Проблемы таковы.
1) Длинная цепочка преобразований, которая идет с искажением информации, особенно когда ситуация в бизнесе меняется в ходе проекта и надо изменить уже проработанные постановки.
2) Интервью с заказчиком дают противоречивую информацию, выявление противоречий и согласование - непросто и небыстро, особенно если интервью параллельно ведут несколько специалистов.
3) Описания бизнес-процессов в формальных нотациях (ARIS, IDEF0, BPMN, UML) непонятны заказчикам, они не могут их верифицировать, при этом создается ложное ощущение полноты информации. То же касается структур данных - диаграмм классов и ER-диаграмм. Впрочем, я лично тут не до конца согласен: да. полные нотации действительно непонятны, но если использовать ограниченные нотации и вести коммуникацию, то верификацию можно получить.
4) Требования часто скрытым образом содержат частные проектные решения, выработанные конкретным аналитиком, и неясно, что в них обусловлено предметной областью, а что - доопределено им произвольно. При этом решения являются фрагментарными, локальными.
5) Функциональные требования дают плохую основу для декомпозиции системы, так как не дают представления о структуре системы.
Как эти проблемы решает Event Storming? Прежде всего, он заменяет длительную распределенную коммуникацию краткой синхронной, на встречу собирают представителей бизнеса и разработчиков вместе. Получается общее видение предметной области на общем языке, который разработчики узнают от бизнеса.
Вместо процессного представления применяется гораздо более простой формализм: события и реакция на них людей с помощью существующих систем или в ручном режиме. При этом фиксируются проблемные точки и потребности автоматизации. При этом, за счет одновременного присутствия всех представителей бизнеса противоречия быстро вскрываются и обсуждаются на месте. Фиксируется необходимая информация и команды, которые дают люди, а при детальной проработке - агрегаты (бизнес-объекты), с помощью которых организуется процесс.
Есть три уровня рассмотрения: на верхнем получается карта событий, роли людей в их обработке и команды, которые они выдают, на втором - события увязываются между собой в цепочки процессов и формулируются правила обработки, а на третьем как раз выявляют агрегаты информации, передаваемые по процессу и хранящие историю. Все это фиксируется с помощью карточек разного цвета, соответствующего разным типам объектов, на большой доске. В докладе были конкретные примеры Дениса из реальных проектах.
Отметим, что такое представление о предметной области хорошо совместимо с современными шаблонами реализации. основанными на независимых сервисах, управляемой событиями (event sourcing) и сообщениями, и разделяющем чтение информации и команды (CQRS).
Применение начать лучше внутри команды, для синхронизации контекстов и онбординга новичков. А далее можно попробовать с лояльным клиентом на небольшом проекте. получить опыт и расширять использование, делиться с коллегами. Event storming хорошо применим для большинства проектов. В нем нет необходимости для простых систем с CRUD операциями и слабой бизнес-логикой. Для отчетных систем есть модификация model storming - там нужен фокус на данных и их обработке.
Источники на русском - Сергей Баранов и Евгений Пешков, на английском - Брандолини и khononov (в процессе перевода).
1) Длинная цепочка преобразований, которая идет с искажением информации, особенно когда ситуация в бизнесе меняется в ходе проекта и надо изменить уже проработанные постановки.
2) Интервью с заказчиком дают противоречивую информацию, выявление противоречий и согласование - непросто и небыстро, особенно если интервью параллельно ведут несколько специалистов.
3) Описания бизнес-процессов в формальных нотациях (ARIS, IDEF0, BPMN, UML) непонятны заказчикам, они не могут их верифицировать, при этом создается ложное ощущение полноты информации. То же касается структур данных - диаграмм классов и ER-диаграмм. Впрочем, я лично тут не до конца согласен: да. полные нотации действительно непонятны, но если использовать ограниченные нотации и вести коммуникацию, то верификацию можно получить.
4) Требования часто скрытым образом содержат частные проектные решения, выработанные конкретным аналитиком, и неясно, что в них обусловлено предметной областью, а что - доопределено им произвольно. При этом решения являются фрагментарными, локальными.
5) Функциональные требования дают плохую основу для декомпозиции системы, так как не дают представления о структуре системы.
Как эти проблемы решает Event Storming? Прежде всего, он заменяет длительную распределенную коммуникацию краткой синхронной, на встречу собирают представителей бизнеса и разработчиков вместе. Получается общее видение предметной области на общем языке, который разработчики узнают от бизнеса.
Вместо процессного представления применяется гораздо более простой формализм: события и реакция на них людей с помощью существующих систем или в ручном режиме. При этом фиксируются проблемные точки и потребности автоматизации. При этом, за счет одновременного присутствия всех представителей бизнеса противоречия быстро вскрываются и обсуждаются на месте. Фиксируется необходимая информация и команды, которые дают люди, а при детальной проработке - агрегаты (бизнес-объекты), с помощью которых организуется процесс.
Есть три уровня рассмотрения: на верхнем получается карта событий, роли людей в их обработке и команды, которые они выдают, на втором - события увязываются между собой в цепочки процессов и формулируются правила обработки, а на третьем как раз выявляют агрегаты информации, передаваемые по процессу и хранящие историю. Все это фиксируется с помощью карточек разного цвета, соответствующего разным типам объектов, на большой доске. В докладе были конкретные примеры Дениса из реальных проектах.
Отметим, что такое представление о предметной области хорошо совместимо с современными шаблонами реализации. основанными на независимых сервисах, управляемой событиями (event sourcing) и сообщениями, и разделяющем чтение информации и команды (CQRS).
Применение начать лучше внутри команды, для синхронизации контекстов и онбординга новичков. А далее можно попробовать с лояльным клиентом на небольшом проекте. получить опыт и расширять использование, делиться с коллегами. Event storming хорошо применим для большинства проектов. В нем нет необходимости для простых систем с CRUD операциями и слабой бизнес-логикой. Для отчетных систем есть модификация model storming - там нужен фокус на данных и их обработке.
Источники на русском - Сергей Баранов и Евгений Пешков, на английском - Брандолини и khononov (в процессе перевода).
🔥9❤4👍2
Максим Цепков написал отчет о конференции Flow, очень хороший, с конспектами докладов (и моим тоже): https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2023-09-17:_Flow_-_%D0%BA%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D1%8F_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%BE%D0%B2_%D0%BE%D1%82_JUGru_-_%D1%85%D0%BE%D1%80%D0%BE%D1%88%D0%B8%D0%B9_%D1%81%D1%82%D0%B0%D1%80%D1%82
Кажется, нам (я был в этом году членом ПК Flow) удалось затащить в программу довольно много архитектурных докладов, что, с моей точки зрения, крайне полезно для системных аналитиков. Вслед за Максимом хочу отметить доклады Дениса Цветцих про C4 (это уже, кажется, вместе с DDD и ES становится азбукой в ИТ, которую нужно знать всем) и Святослава Котусева про Enterprise Architecture — что архитектура — это не диаграммы рисовать, а поддерживать постоянную коммуникацию с бизнесом, строить дорожные карты развития, инициировать проекты и вообще обеспечивать развитие ИТ в соответствии с потребностями развития бизнеса.
Кажется, нам (я был в этом году членом ПК Flow) удалось затащить в программу довольно много архитектурных докладов, что, с моей точки зрения, крайне полезно для системных аналитиков. Вслед за Максимом хочу отметить доклады Дениса Цветцих про C4 (это уже, кажется, вместе с DDD и ES становится азбукой в ИТ, которую нужно знать всем) и Святослава Котусева про Enterprise Architecture — что архитектура — это не диаграммы рисовать, а поддерживать постоянную коммуникацию с бизнесом, строить дорожные карты развития, инициировать проекты и вообще обеспечивать развитие ИТ в соответствии с потребностями развития бизнеса.
👍22
Давно хотел похулиганить и провести мини-игру на понимание требований, и наконец на Flow это получилось сделать. Участникам (большое им спасибо!) были выданы требования к картине. Вот их результаты. Как вам кажется — какая картина наиболее адекватно удовлетворяет потребность заказчика? И что пошло не так в остальных случаях? 🤣
😁26
В общем, раскрываю интригу предыдущих картинок. ТЗ на самом деле было в двух вариантах: одно детальное, другое верхнеуровневое.
Детальное ТЗ:
В принципе, несомненно, у всех что-то получилось, Что можно отметить:
1) Участники были достаточно опытные, чтобы не наваливать вперемешку коров, цветы и птиц, даже если они вперемешку указаны в ТЗ, и в целом картина почти ни у кого не разваливается, как часто бывает в иллюстрациях к этой игре;
2) Команда с летающими коровами пошутила уже надо мной: "
3) Заказчик не проверил заранее наличие необходимых компетенций в команде! Ну не умеют люди рисовать коров, это не проблема людей, это проблема заказчика, который не провел предварительную квалификацию участников тендера.
4) Обычно этой игрой иллюстрируют снижение креативности и полезности продукта при точном выполнении ТЗ; в целом, эффект прослеживается: есть некоторая монотонность выполнения задания по детализированному ТЗ, а также нарушение ракурса — какие-то цветы видны сбоку, какие-то сверху; какие-то огромны по сравнению с коровами, какие-то мелкие — то есть, при отсутствии указания общей цели системы возникают диспропорции и отсутствует единая точка зрения, мы через систему смотрим на мир с какой точки зрения — сверху или сбоку?.. Не понимая задачу, не построишь правильное отражение мира, хотя все отдельные элементы на месте.
5) Из всех команд только одна нашла возможность опросить заказчика (хотя я заранее говорил о такой возможности), и чаще именно работу этой команды признают наиболее подходящей с точки зрения заказчика.
Вот такое получилось забавное упражнение. С точки зрения чистоты эксперимента научности в нём нет никакой, но как иллюстрация — явно наводит на мысли 🤔
Детальное ТЗ:
Нарисуйте прекрасный летний луг, на котором расположены:
* 10 синих цветов с 5 лепестками каждый
* 5 синих цветов с 6 лепестками каждый
* 12 красных цветов с 6 лепестками каждый
* 2 коровы с 3 чёрными пятнами на боку
* 1 корова с 5 чёрными пятнами на боку
* 3 летящих птицы в левом верхнем углу
* 2 птицы посередине
* 1 солнце с 5 лучами в правом верхнем углу
Верхнеуровневое ТЗ:Нарисуйте прекрасный летний луг с красными и синими цветами в зелёной траве, несколькими коровами и птицами в небе, и сияющим солнцем.
Эта картина должна напоминать нашему клиенту о его детстве в деревне.
Что получилось — можете увидеть в предыдущем посте 😆В принципе, несомненно, у всех что-то получилось, Что можно отметить:
1) Участники были достаточно опытные, чтобы не наваливать вперемешку коров, цветы и птиц, даже если они вперемешку указаны в ТЗ, и в целом картина почти ни у кого не разваливается, как часто бывает в иллюстрациях к этой игре;
2) Команда с летающими коровами пошутила уже надо мной: "
несколькими коровами и птицами в небе", вот что неаккуратный союз "и" в требованиях делает!3) Заказчик не проверил заранее наличие необходимых компетенций в команде! Ну не умеют люди рисовать коров, это не проблема людей, это проблема заказчика, который не провел предварительную квалификацию участников тендера.
4) Обычно этой игрой иллюстрируют снижение креативности и полезности продукта при точном выполнении ТЗ; в целом, эффект прослеживается: есть некоторая монотонность выполнения задания по детализированному ТЗ, а также нарушение ракурса — какие-то цветы видны сбоку, какие-то сверху; какие-то огромны по сравнению с коровами, какие-то мелкие — то есть, при отсутствии указания общей цели системы возникают диспропорции и отсутствует единая точка зрения, мы через систему смотрим на мир с какой точки зрения — сверху или сбоку?.. Не понимая задачу, не построишь правильное отражение мира, хотя все отдельные элементы на месте.
5) Из всех команд только одна нашла возможность опросить заказчика (хотя я заранее говорил о такой возможности), и чаще именно работу этой команды признают наиболее подходящей с точки зрения заказчика.
Вот такое получилось забавное упражнение. С точки зрения чистоты эксперимента научности в нём нет никакой, но как иллюстрация — явно наводит на мысли 🤔
👍11❤8😁4
Когда я разбираю идеи некоторых продуктов — предлагаемых или, к сожалению, уже реализованных, — я частенько вспоминаю отрывок из книги про Винни-Пуха, когда он ловил Слонопотама:
яму приложение, а тогда ведь будет уже поздно, и там ему придётся совершить нужное нам действие -- подписаться на рассылку, совершить покупку, пройти опрос и т.п...
Почему он вообще к нам придёт и почему он будет делать то, что мы хотим — вообще обычно не анализируют. Вот прямо сейчас у меня в работе очередной проект с идеей "мы создадим ресурс с информацией по теме X, к нам придут пользователи, прочитают про X, будут обсуждать X, пройдут опросы по теме X, а мы будем их исследовать и продавать о них информацию всем, кто заинтересуется отношением общества к теме X". Чувствую себя немного Пятачком, очень хочется задать сакраментальный вопрос: — Почему он туда упадёт?
Лет 10 назад я немного соприкоснулся с темой активной социологии и краудсорсинга, и примерно представляю себе — насколько сложно мотивировать пользователя прийти, хоть что-нибудь сделать, да ещё и активно поучаствовать. Это уж должна быть такая животрепещущая тема, которая человека очень волнует, касается напрямую, и на которую он как-то может повлиять на этой платформе, или хотя бы озвучить свою позицию.
Так же обстоит дело и с другими продуктами и сервисами — никто просто так в них не упадёт и делать просто так ничего не будет, если не понимать мотивацию и цели пользователя. На этот счёт есть много техник: от простых user story и относительно простого Impact mapping, до сложных диаграмм типа Motivation Layer в Archimate. А уж теорий под этим ещё больше! И SDT (Self Determination Theory), и Behavioral Design с Behavioral Studies, и какой-нибудь Octalysis (не уверен в его эмпирических основаниях) или Bartle taxonomy of player types (которая как раз основана на массированном исследовании мотивации пользователей онлайн-игр)...
А вы используете какой-нибудь инструмент для проектирования поведения пользователей или анализа реалистичности спроектированного пути пользователя?
...Первое, что пришло Пуху в голову,— вырыть Очень Глубокую Яму, а потом Слонопотам пойдёт гулять и упадёт в эту яму, и...Мне кажется, большинство систем в части поведения пользователей спроектированы именно в такой логике: пользователь будет гулять по Интернету, мурлыкая себе под нос песенку, попадёт в нашу
— Почему? — спросил Пятачок.
— Что — почему? — сказал Пух.
— Почему он туда упадёт?
Пух потёр нос лапой и сказал, что, ну, наверно, Слонопотам будет гулять, мурлыкая себе под нос песенку и, поглядывая на небо — не пойдёт ли дождик, вот он и не заметит Очень Глубокой Ямы, пока не полетит в неё, а тогда ведь будет уже поздно.
Пятачок сказал, что это, конечно, очень хорошая Западня, но что, если дождик уже будет идти?
Пух опять почесал свой нос и сказал, что он об этом не подумал. Но тут же просиял и сказал, что, если дождь уже будет идти, Слонопотам может посмотреть на небо, чтобы узнать, скоро ли дождь перестанет, вот он опять и не заметит Очень Глубокой Ямы, пока не полетит в неё!.. А ведь тогда будет уже поздно.
Почему он вообще к нам придёт и почему он будет делать то, что мы хотим — вообще обычно не анализируют. Вот прямо сейчас у меня в работе очередной проект с идеей "мы создадим ресурс с информацией по теме X, к нам придут пользователи, прочитают про X, будут обсуждать X, пройдут опросы по теме X, а мы будем их исследовать и продавать о них информацию всем, кто заинтересуется отношением общества к теме X". Чувствую себя немного Пятачком, очень хочется задать сакраментальный вопрос: — Почему он туда упадёт?
Лет 10 назад я немного соприкоснулся с темой активной социологии и краудсорсинга, и примерно представляю себе — насколько сложно мотивировать пользователя прийти, хоть что-нибудь сделать, да ещё и активно поучаствовать. Это уж должна быть такая животрепещущая тема, которая человека очень волнует, касается напрямую, и на которую он как-то может повлиять на этой платформе, или хотя бы озвучить свою позицию.
Так же обстоит дело и с другими продуктами и сервисами — никто просто так в них не упадёт и делать просто так ничего не будет, если не понимать мотивацию и цели пользователя. На этот счёт есть много техник: от простых user story и относительно простого Impact mapping, до сложных диаграмм типа Motivation Layer в Archimate. А уж теорий под этим ещё больше! И SDT (Self Determination Theory), и Behavioral Design с Behavioral Studies, и какой-нибудь Octalysis (не уверен в его эмпирических основаниях) или Bartle taxonomy of player types (которая как раз основана на массированном исследовании мотивации пользователей онлайн-игр)...
А вы используете какой-нибудь инструмент для проектирования поведения пользователей или анализа реалистичности спроектированного пути пользователя?
👍21
Вот интересно, в очередной раз столкнулся: люди в программирование умеют, а в написание документов совсем не умеют. Не могут ни структуру документа построить, ни обеспечить логику чтения, ни проконтролировать полноту и целостность. Не знают — о чем нужно писать, о чём нет; не понимают — в какой раздел вставить информацию.
Не понимаю: я к написанию документа подхожу так же, как к проектированию системы: вот здесь у нас вот это, вот тут у нас вот то; сначала пишем об этом, потом о том. Пользователь, когда будет читать, должен получать информацию вот в таком порядке; вот это основное, вот это дополнительное, вот тут нужно сослаться на такой-то раздел, а тут оставить предупреждение.
Всё точно так же, как с системой. Но почему они могут тогда что-то запрогать, но не могут это описать?! Позвольте, а как же они тогдаслужили в очистке программируют-то?
Не понимаю: я к написанию документа подхожу так же, как к проектированию системы: вот здесь у нас вот это, вот тут у нас вот то; сначала пишем об этом, потом о том. Пользователь, когда будет читать, должен получать информацию вот в таком порядке; вот это основное, вот это дополнительное, вот тут нужно сослаться на такой-то раздел, а тут оставить предупреждение.
Всё точно так же, как с системой. Но почему они могут тогда что-то запрогать, но не могут это описать?! Позвольте, а как же они тогда
👍20🤡2
BRS, BRD, SRS, FRS, PRD, ФТ, ФЗ, ТЗ — у нас так много названий документов! Каждый раз, когда я прихожу на тренинг в новую компанию, сталкиваюсь с какими-то своими названиями.
А как у вас называются основные документы, которые вы разрабатываете?
Сталкивались ли с тем, что при переходе из одной компании в другую названия документов меняется? Остается ли при этом суть, или тоже меняется? И как во всём этом не запутаться?
А как у вас называются основные документы, которые вы разрабатываете?
Сталкивались ли с тем, что при переходе из одной компании в другую названия документов меняется? Остается ли при этом суть, или тоже меняется? И как во всём этом не запутаться?
👍10
Какая у меня складывается картина по результатам обсуждения документов, тезисно:
1. Почти у всех есть разделение на бизнес-документы и постановки задач для разработчиков.
2. Когда речь идёт о бизнес-требованиях, скорее имеются в виду "требования от бизнеса [к системе]", а не "требования к бизнесу". (Поэтому возникают такие гибриды, как "Бизнес-функциональные требования".)
3. Поэтому в документах бизнес-требований зачастую появляется уже и система, и описание процессов, т.к. уровень требований склонен "съезжать" в сторону автоматизации. При этом крайне редко используется анализ потребностей бизнеса, уточнение целеполагания (а правильную ли мы выбрали цель?), мотивации различных стейкхолдеров и анализ экономической эффективности решения. В общем, вся эта часть с анализом воздействий на бизнес и эффекта для бизнеса замыливается или вовсе не производится. Требования бизнеса фиксируются "как есть", некритически.
4. Очень редко упоминаются отдельно требования пользователей, стейкхолдеров, рынка или требования к продукту. Кажется, почти никто их отдельно не фиксирует и не анализирует. То есть, от верхнеуровневых требований бизнеса сразу же "проскакивают" к функциональным требованиям, без анализа процессов использования, целей и ожиданий пользователей. В лучшем случае этот анализ "прилипает" к документам функциональных требований.
5. Самый понятный документ — спецификация функциональных требований, причем уже в виде детальной постановки задачи. Непонятно, куда здесь девается процесс предложения и выбора альтернативных решений, видимо, он осуществляется в фоновом режиме и не фиксируется, это та самая скрытая работа по проектированию. Собственно, часто бывает, что функциональные требования фиксируются-то уже постфактум, после разработки.
В целом, кажется, что практика идёт по пути упрощения, и всё стремится к двум документам: БФТ/BRD и постановке (ТЗ/FSD). За бортом остаётся целеполагание и анализ бизнес-кейса, принятие решения о том, что цель в принципе достигается созданием какой-либо ИТ-системы; анализ и проектирование процессов использования, целей и ожиданий пользователей; выбор технических решений.
В этом смысле интересно, что системная инженерия делает акцент как раз на обратном: ConOps — это анализ бизнес-кейса, или миссии, выше уже стратегия компании; StRS — Stakeholders Requirements Specification (включая ожидания пользователей), OpsCon — операционная концепция, или концепция эксплуатации — а что с системой может происходить, штатно и нештатно, кто за это отвечает и как вообще с системой работать — извлекать пользу, сопровождать, обеспечивать ресурсами, ремонтировать, утилизировать и т.п. А уже потом — SysRS и SRS — системные требования и требования к ПО.
1. Почти у всех есть разделение на бизнес-документы и постановки задач для разработчиков.
2. Когда речь идёт о бизнес-требованиях, скорее имеются в виду "требования от бизнеса [к системе]", а не "требования к бизнесу". (Поэтому возникают такие гибриды, как "Бизнес-функциональные требования".)
3. Поэтому в документах бизнес-требований зачастую появляется уже и система, и описание процессов, т.к. уровень требований склонен "съезжать" в сторону автоматизации. При этом крайне редко используется анализ потребностей бизнеса, уточнение целеполагания (а правильную ли мы выбрали цель?), мотивации различных стейкхолдеров и анализ экономической эффективности решения. В общем, вся эта часть с анализом воздействий на бизнес и эффекта для бизнеса замыливается или вовсе не производится. Требования бизнеса фиксируются "как есть", некритически.
4. Очень редко упоминаются отдельно требования пользователей, стейкхолдеров, рынка или требования к продукту. Кажется, почти никто их отдельно не фиксирует и не анализирует. То есть, от верхнеуровневых требований бизнеса сразу же "проскакивают" к функциональным требованиям, без анализа процессов использования, целей и ожиданий пользователей. В лучшем случае этот анализ "прилипает" к документам функциональных требований.
5. Самый понятный документ — спецификация функциональных требований, причем уже в виде детальной постановки задачи. Непонятно, куда здесь девается процесс предложения и выбора альтернативных решений, видимо, он осуществляется в фоновом режиме и не фиксируется, это та самая скрытая работа по проектированию. Собственно, часто бывает, что функциональные требования фиксируются-то уже постфактум, после разработки.
В целом, кажется, что практика идёт по пути упрощения, и всё стремится к двум документам: БФТ/BRD и постановке (ТЗ/FSD). За бортом остаётся целеполагание и анализ бизнес-кейса, принятие решения о том, что цель в принципе достигается созданием какой-либо ИТ-системы; анализ и проектирование процессов использования, целей и ожиданий пользователей; выбор технических решений.
В этом смысле интересно, что системная инженерия делает акцент как раз на обратном: ConOps — это анализ бизнес-кейса, или миссии, выше уже стратегия компании; StRS — Stakeholders Requirements Specification (включая ожидания пользователей), OpsCon — операционная концепция, или концепция эксплуатации — а что с системой может происходить, штатно и нештатно, кто за это отвечает и как вообще с системой работать — извлекать пользу, сопровождать, обеспечивать ресурсами, ремонтировать, утилизировать и т.п. А уже потом — SysRS и SRS — системные требования и требования к ПО.
👍16🔥4
На канале Systems.Education опубликован мой доклад на Flow'23: https://youtu.be/HzynqWGKehQ Enjoy!
🔥13👍7
Forwarded from Системный сдвиг
Flow23-Kupriyanov.pdf
3 MB
Рассказал на Flow про скрытую работу по проектированию систем, которую выполняет системный аналитик. Хотя какая там скрытая! Вполне даже явная, в половине вакансий написано: проектировать интерфейсы пользователя, Figma; проектировать REST API, разрабатывать спецификацию в OpenAPI; знать Kafka и RabbitMQ, уметь на собеседовании объяснить разницу между AMQP и MQTT; знать SQL, уметь профилировать и оптимизировать запросы, разрабатывать физическую модель; уметь нарезать монолит на микросервисы. И аналитики такие: ЧТОА?
В общем, ловите презентацию, там есть немного ссылок по темам.
В общем, ловите презентацию, там есть немного ссылок по темам.
👍25🔥1
В нескольких обсуждениях ценности системного аналитика проскользнул аргумент "один системный аналитик обеспечивает работой 5-6 разработчиков, а то и 8", — поэтому, получается, такое разделение труда выгодно.
Я сам в таких проектах был; ну 8 — это уже как-то много, а 4-6 — легко, вполне верю. Но тут я начал у всех выяснять — а какое у них соотношение? И большинство ответов пока — 1:2, а то и 1:1‼️
Наоборот, людей удивляет, что число разработчиков может быть больше. Кажется, что если в процесс уж встроены аналитики, то их нужно прямо много. Что опровергает гипотезу об экономической выгоде чисто по соотношению ролей. Видимо, дело в чем-то другом.
А какое у вас соотношение? Сколько приходится разработчиков на одного аналитика?
Я сам в таких проектах был; ну 8 — это уже как-то много, а 4-6 — легко, вполне верю. Но тут я начал у всех выяснять — а какое у них соотношение? И большинство ответов пока — 1:2, а то и 1:1‼️
Наоборот, людей удивляет, что число разработчиков может быть больше. Кажется, что если в процесс уж встроены аналитики, то их нужно прямо много. Что опровергает гипотезу об экономической выгоде чисто по соотношению ролей. Видимо, дело в чем-то другом.
А какое у вас соотношение? Сколько приходится разработчиков на одного аналитика?
👍4