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