«Поставщик задачи» — это или человек, работающий в предметной области, у которого есть своя работа, благодаря которой он и узнал особенности предметной области. Или аналитик, который формулирует задачи для разработчиков на основании выявления и анализа требований. Для того чтобы «поставщику задачи» делать свою работу хорошо, ему нужно оставаться в контексте, а не плясать вокруг разработчиков по первому требованию.
Еще возможны ситуации, когда «поставщик задачи» на самом деле не знает, каким должен быть результат, потому что у него недостаточно компетенций, но не признается в этом. Он может заболеть, уйти в отпуск или уволиться, не дождавшись результата. Как тогда проверить, выполнено ли задание?
Понимаю, сложно в это поверить, но не вокруг разработчиков мир вертится. Другие роли тоже работают. И иногда выяснить, каким же всё-таки должен быть результат, занимает больше времени, чем написание кода. А процесс документирования требований - это очень важная часть их анализа. Именно при документировании обычно всплывают подводные камни и логические противоречия.
Ваш концепт «одной комнаты» — это как «сферический конь в вакууме», если коротко.
@krakenkaken Приятно, что именно вы поддерживаете мое мнение :) Я знакома с вашим продуктом Gramax. И мне кажется, что это именно тот инструмент, который может стереть барьер между нетехническими ролями и подходом «Everything as Code». Немного грустно, что самые «вкусные» функции совместной работы есть только в Enterprise версии. Хотя я, безусловно, понимаю, почему так получилось.
В части написания спецификаций требований AI-агентами я также тестировала продукт Spec Kit, и, на мой взгляд, он пока «очень сырой». Помимо обычных проблем, с которыми можно столкнуться при работе с ИИ, там есть очень опасная подмена понятий именно в части работы с требованиями.
Spec Kit предполагает, что ИИ опишет именно спецификацию, необходимую для работы AI-агента. По сути, он декомпозирует уже выявленные, проанализированные и задокументированные требования на более мелкие задачи, которые способны выполнить AI-агенты. При такой декомпозиции он может добавить что-то от себя и немного приврать. Проверка таких автоматически сгенерированных требований — это очень утомительная работа. Как по мне, проще декомпозировать требования самостоятельно.
Конечно, ИИ может и сам полностью придумать требования и сам их реализовать. Тогда получится создать продукт, который теоретически с определенной долей вероятности будет востребован пользователями. А может и не будет востребован. Это как играть в русскую рулетку.
Глядя на все проблемы, описанные в статье, почему-то хочется сказать: «Это у вас просто аналитика нормального не было» :) Аналитики-то знают, что «надо интегрироваться с партнёром», «нужно, чтобы клиенту было удобно» — это не требования, а их отсутствие. А ещё они знают, чем требования отличаются от особенностей реализации и архитектурного решения. И даже не забывают описывать альтернативные сценарии :)
Спасибо, за статью. Было бы интересно узнать ваше видение инструментов мотивации двух категорий сотрудников: "звезд" и "самопровозглашенных звезд". И есть ли какие-то признаки, по которым можно понять, что ресурсы, затраченные на мотивацию окупаются или не окупаются?
"Сделать все" - эта проблема стара как мир :) А классические проблемы требуют классического решения. Если заказчик не может или не хочет детализировать требования стоит применить старое доброе интервьюирование и технику "5 почему".
Проблема импорта замещения не так стара, она стала актуальна последние лет 10. Тем не менее, если обратится к классикам и на этот вопрос тоже можно найти ответ :) Так Том ДеМарко в своей книге "Deadline. Роман об управлении проектами" описывает особенности работы над проектом QuicckerStill, функционал которого практически полностью копирует функционал уже имеющихся на рынке решений. Для того чтобы сократить сроки реализации, команда проекта отказалась от этапов выявления и анализа требования и сразу приступила к проектированию системы. При этом основным источником пользовательских и функциональных требований выступало руководство пользователя уже реализованного, успешного на рынке аналога.
Лично мне, такой подход кажется удачной идеей. Не нужно изобретать велосипед, если кто-то уже сделал это за вас. Более того меня как конечного пользователя продуктов разработанных как аналоги ушедших с рынка, очень радует копирование функционала и использование похожих элементов интерфейса. Потому что я могу быстро начать использовать новый продукт, пере использовать свой пользовательский опыт и не тратить время на обучение.
В целом, мне кажется что описанные вами проблемы больше относятся к работе с возражениями, чем к выявлению требований.
Приятно и не привычно видеть на habr комментарии не нацеленные на холивар :)
Оксюморон, есть и он был добавлен осознанно. На стадии инициации мы очень приблизительно определяем границы проекта. И неважно используется проектный или продуктовый подход. Прежде чем начать какую-либо доработку нужно понимать хватит ли нам времени и бюджета на то чтобы ее реализовать. Да, agile учит нас быть гибкими. Да, нужно быть готовыми к изменениям. Но надо понимать что изменения могут быть разными. Если мы можем выявить какие-либо требования и риски на ранних этапах, нужно это сделать, не зависимо от используемых методологий. И это не мешает нам заложить лаг по времени и бюджету на случай если появятся требования и риски которые мы даже представить себе не могли. Многие проповедники agile часто забывают что изменения все-таки должны быть обоснованы. Например, не стоит постоянно вносить правки в архитектуру, потому что вышел новый фреймворк или СУБД. Все хорошо в меру. И с гибкостью тоже не стоит перебарщивать. Если мы занимаемся продуктовой разработкой можно рассчитывать что продукт будет приносить деньги, на которые можно будет пополнять бюджет на разработку нового функционала. Но понять хватит ли нам этих денег мы сможем только оценив стоимость разработки. А для оценки стоимости нам нужно хотя бы верхнеуровнево понимать что входит в этот новый функционал (описать вариант реализации).
Это очень интересный вопрос, дискутировать о котором можно часами. Вы буквально открыли ящик Пандоры :) В начале позволю себе немного придраться к терминам. Обратите внимание, на фазе инициации не была написана ни одна строчка кода :) Мы только выявляли, анализировали и документировали требования. Частично были затронуты некоторые вопросы из сферы управления проектами. Думаю что описанной в статье информации недостаточно для того, чтобы определить используемую модель управления разработкой. Тем не менее давайте представим что в статье использовалась следующая формулировка "В DTB разделяют идеологию гибких методологий управления проектами". И чтобы не вдаваться в детали будем придерживаться гипотезы, о том что все методологии управления проектами можно разделить на две группы: водопад (каскад) и итерационные (гибкие). На мой взгляд, тот факт что аналитику нужно выполнять свою работу в определенном порядке, еще не говорит о том что он работает по водопаду. Поясню почему так: - Несмотря на то что на этапе первичного анализа мы выявили требования по работе с общим счетом из мобильных приложения клиента DBT и в целом понятно как могут использовать общий счет юр. лица. Мы сознательно отложили анализ этих требований на более поздние этапы. По сути это крупные итерации по выявлению требований. - Каждый созданные аналитиком артефакт обсуждался со стейкхолдерами и корректировался на основании обсуждения. Это оперативное получение обратной связи и работа с изменениями требований. - На основании первичного анализа были определены границы проекта, но не был составлен детальный план проекта, которого нужно было бы придерживаться при работе по водопаду. Таким образом, то что аналитик работал последовательно, не значит что он не был гибким. Просто гнулся он в правильном направлении :) Рада буду прочитать ваши контраргументы. Будет здорово, если вы напишете, почему эта модель относится к водопаду :)
Поясните что вы подразумеваете под "Это" :) У меня готов список контр аргументов, но возможно я не совсем правильно поняла комментарий и надумала проблему, которую хочу прокомментировать :)
Описанный вами подход никак не противоречит тому что написано в статье. Я также предполагаю что аналитик начинает свою работу с определения бизнес — проблемы и бизнес — цели https://disk.yandex.ru/i/zJ_nRs1sABiJaA . Бизнес требования, как и требования любого другого типа могут быть при необходимости декомпозированы. Но сути дела это не меняет. Заказчик может сформулировать бизнес требования самостоятельно, это тоже правда. А может и не сформулировать и тогда аналитику нужно ему помочь. Мне кажется мы с вами говорим об одном, но только разными словами :)
Спасибо за интерес к статье. Вы правы, в статье рассматривается конкретный кейс. Действительно каждый проект индивидуален и используемые на нем инструменты зависят от многих факторов. Это предметная область, размер компании, используемые в компании методологии управления разработкой и даже прошлый опыт участников команды проекта. С универсальными подходами можно ознакомится в теории. Я, конечно, не претендую на лавры Вигерса и не думаю что можно в одной статье описать больше инструментов чем в SEBoK и BABOK. Но у универсальных подходов есть и свои недостатки. Бывает такое что начитавшись теории, приходишь на реальный проект и просто не знаешь с чего начать. Учебные проекты как раз и нужны, для того чтобы приземлить теорию в асфальт практики. Лучше попробовать описать требования хотя бы для одного проекта с использованием конкретного инструмента, чем долго читать теорию и ждать когда найдется компания которая слово в слово следуют описанным в теории методологиям, и очень ищет аналитика педанта.
«Поставщик задачи» — это или человек, работающий в предметной области, у которого есть своя работа, благодаря которой он и узнал особенности предметной области. Или аналитик, который формулирует задачи для разработчиков на основании выявления и анализа требований. Для того чтобы «поставщику задачи» делать свою работу хорошо, ему нужно оставаться в контексте, а не плясать вокруг разработчиков по первому требованию.
Еще возможны ситуации, когда «поставщик задачи» на самом деле не знает, каким должен быть результат, потому что у него недостаточно компетенций, но не признается в этом. Он может заболеть, уйти в отпуск или уволиться, не дождавшись результата. Как тогда проверить, выполнено ли задание?
Понимаю, сложно в это поверить, но не вокруг разработчиков мир вертится. Другие роли тоже работают. И иногда выяснить, каким же всё-таки должен быть результат, занимает больше времени, чем написание кода. А процесс документирования требований - это очень важная часть их анализа. Именно при документировании обычно всплывают подводные камни и логические противоречия.
Ваш концепт «одной комнаты» — это как «сферический конь в вакууме», если коротко.
Вот еще один кандидат на роль «русского бизнес-романа» — «Команда, которую создал я» А. Ермак.
@krakenkaken Приятно, что именно вы поддерживаете мое мнение :) Я знакома с вашим продуктом Gramax. И мне кажется, что это именно тот инструмент, который может стереть барьер между нетехническими ролями и подходом «Everything as Code». Немного грустно, что самые «вкусные» функции совместной работы есть только в Enterprise версии. Хотя я, безусловно, понимаю, почему так получилось.
В части написания спецификаций требований AI-агентами я также тестировала продукт Spec Kit, и, на мой взгляд, он пока «очень сырой». Помимо обычных проблем, с которыми можно столкнуться при работе с ИИ, там есть очень опасная подмена понятий именно в части работы с требованиями.
Spec Kit предполагает, что ИИ опишет именно спецификацию, необходимую для работы AI-агента. По сути, он декомпозирует уже выявленные, проанализированные и задокументированные требования на более мелкие задачи, которые способны выполнить AI-агенты. При такой декомпозиции он может добавить что-то от себя и немного приврать. Проверка таких автоматически сгенерированных требований — это очень утомительная работа. Как по мне, проще декомпозировать требования самостоятельно.
Конечно, ИИ может и сам полностью придумать требования и сам их реализовать. Тогда получится создать продукт, который теоретически с определенной долей вероятности будет востребован пользователями. А может и не будет востребован. Это как играть в русскую рулетку.
Глядя на все проблемы, описанные в статье, почему-то хочется сказать: «Это у вас просто аналитика нормального не было» :)
Аналитики-то знают, что «надо интегрироваться с партнёром», «нужно, чтобы клиенту было удобно» — это не требования, а их отсутствие. А ещё они знают, чем требования отличаются от особенностей реализации и архитектурного решения. И даже не забывают описывать альтернативные сценарии :)
Спасибо, за статью. Было бы интересно узнать ваше видение инструментов мотивации двух категорий сотрудников: "звезд" и "самопровозглашенных звезд". И есть ли какие-то признаки, по которым можно понять, что ресурсы, затраченные на мотивацию окупаются или не окупаются?
"Сделать все" - эта проблема стара как мир :) А классические проблемы требуют классического решения. Если заказчик не может или не хочет детализировать требования стоит применить старое доброе интервьюирование и технику "5 почему".
Проблема импорта замещения не так стара, она стала актуальна последние лет 10. Тем не менее, если обратится к классикам и на этот вопрос тоже можно найти ответ :) Так Том ДеМарко в своей книге "Deadline. Роман об управлении проектами" описывает особенности работы над проектом QuicckerStill, функционал которого практически полностью копирует функционал уже имеющихся на рынке решений. Для того чтобы сократить сроки реализации, команда проекта отказалась от этапов выявления и анализа требования и сразу приступила к проектированию системы. При этом основным источником пользовательских и функциональных требований выступало руководство пользователя уже реализованного, успешного на рынке аналога.
Лично мне, такой подход кажется удачной идеей. Не нужно изобретать велосипед, если кто-то уже сделал это за вас. Более того меня как конечного пользователя продуктов разработанных как аналоги ушедших с рынка, очень радует копирование функционала и использование похожих элементов интерфейса. Потому что я могу быстро начать использовать новый продукт, пере использовать свой пользовательский опыт и не тратить время на обучение.
В целом, мне кажется что описанные вами проблемы больше относятся к работе с возражениями, чем к выявлению требований.
?
Приятно и не привычно видеть на habr комментарии не нацеленные на холивар :)
Оксюморон, есть и он был добавлен осознанно. На стадии инициации мы очень приблизительно определяем границы проекта. И неважно используется проектный или продуктовый подход. Прежде чем начать какую-либо доработку нужно понимать хватит ли нам времени и бюджета на то чтобы ее реализовать. Да, agile учит нас быть гибкими. Да, нужно быть готовыми к изменениям. Но надо понимать что изменения могут быть разными. Если мы можем выявить какие-либо требования и риски на ранних этапах, нужно это сделать, не зависимо от используемых методологий. И это не мешает нам заложить лаг по времени и бюджету на случай если появятся требования и риски которые мы даже представить себе не могли.
Многие проповедники agile часто забывают что изменения все-таки должны быть обоснованы. Например, не стоит постоянно вносить правки в архитектуру, потому что вышел новый фреймворк или СУБД. Все хорошо в меру. И с гибкостью тоже не стоит перебарщивать.
Если мы занимаемся продуктовой разработкой можно рассчитывать что продукт будет приносить деньги, на которые можно будет пополнять бюджет на разработку нового функционала. Но понять хватит ли нам этих денег мы сможем только оценив стоимость разработки. А для оценки стоимости нам нужно хотя бы верхнеуровнево понимать что входит в этот новый функционал (описать вариант реализации).
Это очень интересный вопрос, дискутировать о котором можно часами. Вы буквально открыли ящик Пандоры :)
В начале позволю себе немного придраться к терминам. Обратите внимание, на фазе инициации не была написана ни одна строчка кода :) Мы только выявляли, анализировали и документировали требования. Частично были затронуты некоторые вопросы из сферы управления проектами. Думаю что описанной в статье информации недостаточно для того, чтобы определить используемую модель управления разработкой.
Тем не менее давайте представим что в статье использовалась следующая формулировка "В DTB разделяют идеологию гибких методологий управления проектами". И чтобы не вдаваться в детали будем придерживаться гипотезы, о том что все методологии управления проектами можно разделить на две группы: водопад (каскад) и итерационные (гибкие). На мой взгляд, тот факт что аналитику нужно выполнять свою работу в определенном порядке, еще не говорит о том что он работает по водопаду.
Поясню почему так:
- Несмотря на то что на этапе первичного анализа мы выявили требования по работе с общим счетом из мобильных приложения клиента DBT и в целом понятно как могут использовать общий счет юр. лица. Мы сознательно отложили анализ этих требований на более поздние этапы. По сути это крупные итерации по выявлению требований.
- Каждый созданные аналитиком артефакт обсуждался со стейкхолдерами и корректировался на основании обсуждения. Это оперативное получение обратной связи и работа с изменениями требований.
- На основании первичного анализа были определены границы проекта, но не был составлен детальный план проекта, которого нужно было бы придерживаться при работе по водопаду.
Таким образом, то что аналитик работал последовательно, не значит что он не был гибким. Просто гнулся он в правильном направлении :)
Рада буду прочитать ваши контраргументы. Будет здорово, если вы напишете, почему эта модель относится к водопаду :)
Поясните что вы подразумеваете под "Это" :) У меня готов список контр аргументов, но возможно я не совсем правильно поняла комментарий и надумала проблему, которую хочу прокомментировать :)
Описанный вами подход никак не противоречит тому что написано в статье. Я также предполагаю что аналитик начинает свою работу с определения бизнес — проблемы и бизнес — цели https://disk.yandex.ru/i/zJ_nRs1sABiJaA . Бизнес требования, как и требования любого другого типа могут быть при необходимости декомпозированы. Но сути дела это не меняет. Заказчик может сформулировать бизнес требования самостоятельно, это тоже правда. А может и не сформулировать и тогда аналитику нужно ему помочь. Мне кажется мы с вами говорим об одном, но только разными словами :)
Рада, что вам было интересно :)
Спасибо за интерес к статье. Вы правы, в статье рассматривается конкретный кейс. Действительно каждый проект индивидуален и используемые на нем инструменты зависят от многих факторов. Это предметная область, размер компании, используемые в компании методологии управления разработкой и даже прошлый опыт участников команды проекта. С универсальными подходами можно ознакомится в теории. Я, конечно, не претендую на лавры Вигерса и не думаю что можно в одной статье описать больше инструментов чем в SEBoK и BABOK. Но у универсальных подходов есть и свои недостатки. Бывает такое что начитавшись теории, приходишь на реальный проект и просто не знаешь с чего начать. Учебные проекты как раз и нужны, для того чтобы приземлить теорию в асфальт практики. Лучше попробовать описать требования хотя бы для одного проекта с использованием конкретного инструмента, чем долго читать теорию и ждать когда найдется компания которая слово в слово следуют описанным в теории методологиям, и очень ищет аналитика педанта.