Комментарии 17
Прочитал заметку, и не понял: где тут про управление требованиями хоть что-то? Да еще именно внутри компании. Вы рассказали о том, что у пользователей бывают хотелки, и что обычно они не очень понятно для разработчиков выражаются. Вряд ли это открытие для читателя. В конце предлагается их все брать и анализировать, чтобы получить задачи. Это, видимо, и есть управление требованиями. В чем смысл написания этого текста?
Спасибо за байки.
Управление требованиями — это контроль жизненного цикла требований. А тут просто про то, что надо выяснять истинные потребности и устранять противоречия. Ну ок.
По сути, про один кусок этого цикла.
при этом акцент сделан не на том, что это кусок цикла, а на других вещах. Заголовку статьи соответствует чуть менее чем полностью
Ну очевидно, товарищ решил написать статью, чтобы получить приглашение — так все делают, это правильный путь. Но полагаю, для этого нужно копнуть глубже. Например, взять готовые методологические наработки управления требованиями (допустим, из pmbok) и рассказать о реальной практике применения каких-то из них в своей работе. С примерами. Например, как составляли матрицу требований, ранжировали ее и т.п.
В данном случае это как раз по мотивам практики работы, и статья не предполагает охватить всю тему управления проектами, требованиями, командами, качеством реализации требований и т.д.
А охватывает только часть между «хотелками» и «реализацией», которая именно про сами требования. Возможно название ввело кого-то в заблуждение и тут ожидали увидеть например как меняются требования в процессе разработки и что с этим делать и.т.д. Но тут этого нет.
Если тут кто-то хотел увидеть, как и на какое время вперёд задачи можно планировать, распределять, приоритизровать, как их декомпозировать — то тут этого тоже нет (мне кажется, что тема статьи сильно о другом). Так же тут нет работы с результатами реализации требований.
Возможно стоит вынести в предисловие список того, чего эта статья не пытается раскрыть, чтобы не давать ложных ожиданий. Так как тема узкая и конкретная. К нам влетают хотелки/требования/пожелания/проблемы и т.д. а мы с ними работаем и на выходе получаем то, что пригодно для разработки. Всё.
Мне кажется, что нельзя, неправильно и вообще нет смысла брать и писать статью «сразу обо всём», пересказывая всё что существует в мире на эту тему.
А охватывает только часть между «хотелками» и «реализацией», которая именно про сами требования. Возможно название ввело кого-то в заблуждение и тут ожидали увидеть например как меняются требования в процессе разработки и что с этим делать и.т.д. Но тут этого нет.
Если тут кто-то хотел увидеть, как и на какое время вперёд задачи можно планировать, распределять, приоритизровать, как их декомпозировать — то тут этого тоже нет (мне кажется, что тема статьи сильно о другом). Так же тут нет работы с результатами реализации требований.
Возможно стоит вынести в предисловие список того, чего эта статья не пытается раскрыть, чтобы не давать ложных ожиданий. Так как тема узкая и конкретная. К нам влетают хотелки/требования/пожелания/проблемы и т.д. а мы с ними работаем и на выходе получаем то, что пригодно для разработки. Всё.
Мне кажется, что нельзя, неправильно и вообще нет смысла брать и писать статью «сразу обо всём», пересказывая всё что существует в мире на эту тему.
Ответьте на простой вопрос. Что же тут есть? Часть между хотелками и реализацией это я бы сказал — вообще весь проект. Сначала есть хотелка, потом знак вопроса, потом она реализована. Этот знак вопроса включает в себе не только управление требованиями, а еще кучу всего интересного. И этого в статье тоже, нет. Чего же в ней есть, кроме пары анекдотов?..
1. хотелки
2. описанные задачи готовые к разработке
3. продуманные планы — когда какие задачи делаем, спринты, кварталы или какие-то приоритеты и т.д. — смотря какая система управления проектами/командами используется в конкретном случае
4. реализация задач (программирование и всё что связано с разработкой, включая архитектуру и т.п.)
5. тестирование
6. релиз — задачи доставлены и работают
7. обратная связь по результатам использования
Тут про пункты 1 и 2. Про другие пункты есть другие статьи/материалы от других авторов.
2. описанные задачи готовые к разработке
3. продуманные планы — когда какие задачи делаем, спринты, кварталы или какие-то приоритеты и т.д. — смотря какая система управления проектами/командами используется в конкретном случае
4. реализация задач (программирование и всё что связано с разработкой, включая архитектуру и т.п.)
5. тестирование
6. релиз — задачи доставлены и работают
7. обратная связь по результатам использования
Тут про пункты 1 и 2. Про другие пункты есть другие статьи/материалы от других авторов.
Иногда следует признать ошибку и подумать над тем, как ее не допустить в дальнейшем. Но если вы настаиваете на дискуссии, то…
«Хотелки». Вы написали, что они есть. Вряд ли это новость. Вы написали, что они не формализованы и не понятны, и иногда пересекаются, а иногда достаточно ткнуть пальцем в уже имеющуюся фичу. Вряд ли это важная информация. Каких-то методик для работы с хотелками вы не указали. Ценность информации по хотелкам — ноль. Ну ок, тут есть посыл: юзеры хотят всякого. Причем в заголовке акцент на внутренних юзеров, но каких либо отличий их от внешних, или особенности работы с ними, я не увидел.
Про описанные задачи, готовые к работе, нет вообще ничего — даже какой-никакой классификации, не знаю… вы просто указали, что они получаются каким-то образом из хотелок. Ценность информации — абсолютный ноль.
Когда я захожу на этот ресурс, и вижу заголовок потенциально пересекающийся с моей проф. деятельностью, я радостно читаю статью: вдруг узнаю что-то новое, или получу подтверждение что делаю свою работу правильно, или какая-то важная мысль для понимания сути мироздания промелькнет. А тут — ничего нет, пустота.
Мои комментарии несут ровно одну цель: сказать вам, что заметки не должны быть такими, текст ради текста. Статьи здесь должны быть интересны кому-то из читателей. А читатели, в основном, профессионалы, или около того.
«Хотелки». Вы написали, что они есть. Вряд ли это новость. Вы написали, что они не формализованы и не понятны, и иногда пересекаются, а иногда достаточно ткнуть пальцем в уже имеющуюся фичу. Вряд ли это важная информация. Каких-то методик для работы с хотелками вы не указали. Ценность информации по хотелкам — ноль. Ну ок, тут есть посыл: юзеры хотят всякого. Причем в заголовке акцент на внутренних юзеров, но каких либо отличий их от внешних, или особенности работы с ними, я не увидел.
Про описанные задачи, готовые к работе, нет вообще ничего — даже какой-никакой классификации, не знаю… вы просто указали, что они получаются каким-то образом из хотелок. Ценность информации — абсолютный ноль.
Когда я захожу на этот ресурс, и вижу заголовок потенциально пересекающийся с моей проф. деятельностью, я радостно читаю статью: вдруг узнаю что-то новое, или получу подтверждение что делаю свою работу правильно, или какая-то важная мысль для понимания сути мироздания промелькнет. А тут — ничего нет, пустота.
Мои комментарии несут ровно одну цель: сказать вам, что заметки не должны быть такими, текст ради текста. Статьи здесь должны быть интересны кому-то из читателей. А читатели, в основном, профессионалы, или около того.
Тут не описано про классификацию задач, потому что у нас по сути нет такой классификаци. Мы же не расатриваем здесь баги.
на всё остальное кроме багов у нас есть два вида задач для разработчиков — стори и дев. дев — это когда никакой функционал не меняет внешнюю логику работы, а только что-то внутренне техническое.
А всё что на тему функционала — кусок большого проекта, или одна отдельная независимая фича — это всё равно стори.
Если есть много стори на разные компоненты системы, или даже на один — то под это есть агрегирующая их задача другого типа. Котрая например «внедрить вот такую-то новую большую штуку». И там внутри неё с десяток разных производственных задач.
И эти стори и дев уже раздаются разработчикам.
Возможно у вас есть много типов задач для разработчиков и вам это нужно. У нас вот такого варианта вполне хватает.
на всё остальное кроме багов у нас есть два вида задач для разработчиков — стори и дев. дев — это когда никакой функционал не меняет внешнюю логику работы, а только что-то внутренне техническое.
А всё что на тему функционала — кусок большого проекта, или одна отдельная независимая фича — это всё равно стори.
Если есть много стори на разные компоненты системы, или даже на один — то под это есть агрегирующая их задача другого типа. Котрая например «внедрить вот такую-то новую большую штуку». И там внутри неё с десяток разных производственных задач.
И эти стори и дев уже раздаются разработчикам.
Возможно у вас есть много типов задач для разработчиков и вам это нужно. У нас вот такого варианта вполне хватает.
Кроме того, что есть хотелки, посылы такие:
1. нельзя в сыром виде отдавать хотелки разработчикам
2. нужно понять какую реальную проблему мы решаем
3. нужно смотреть на всю картину из всех этих проблем, и потом уже на основании этого выделять проекты, истории, декомпозировать на технические задачи
4. есть много одинаковых, повторяющихся в НАШЕЙ работе ситуаций, и я описал по самым основным и повторяющимся, что можно с этим сделать. Нарпимер:
4.1. если функционал есть — рассказать человеку как ПРАВИЛЬНО пользоваться
4.2. если много повторяющихся хотелок — обобщить и делать единообразно
4.3. если есть конфликтующие требования — то нужно их пытатсья разрулить, и вот такие варианты есть как их можно разруливать (ясно, что не стоит просто в лоб пытаться реализовать оба конфликтующих требования, иначе при выкате на прод всё сломается нафиг — а такое может быть если один менеджер дал напрямую одному разработчику одну задачу, а другой менеджер дал другому разработчику другую задачу)
Возможно, в вашей практике, и в вашей работе таких проблем не возникает или вы уже знаете как их решать и успешно решаете более сложные проблемы.
Но я вижу в реальной жизни много людей, которые не делают даже описанного в статье, и видел в своей жизни много компаний, которые даже такие простые проблемы не могли решить или даже не пытались. Это существует в реальном мире.
И я рад что у вас этого нет. Но это не повод не делиться опытом.
У нас например в начале проекта в котором я работаю эти проблемы все были и ни одна из них не была решена. Но постепенно мы их все плюс-минус зарешали, хотя иногда до сих пор бывает что кто-то с квадратными глазами вбегает к разработчику и говорит что нужно срочно сделать новую табличку из которой будет что-то как-то куда-то считаться. И разработчик начинает делать.
И приходится потом бегать, рассказывать что у нас уже есть готовая система, которая уже считает и отдаёт то, что нужно, и выдёргивать из рук разработчика наполовину сделанную задачу )))) Но с каждым разом таких единичных случаев всё меньше и меньше.
Ещё раз повторю, я очень рад, что у вас такого нет и всё хорошо.
1. нельзя в сыром виде отдавать хотелки разработчикам
2. нужно понять какую реальную проблему мы решаем
3. нужно смотреть на всю картину из всех этих проблем, и потом уже на основании этого выделять проекты, истории, декомпозировать на технические задачи
4. есть много одинаковых, повторяющихся в НАШЕЙ работе ситуаций, и я описал по самым основным и повторяющимся, что можно с этим сделать. Нарпимер:
4.1. если функционал есть — рассказать человеку как ПРАВИЛЬНО пользоваться
4.2. если много повторяющихся хотелок — обобщить и делать единообразно
4.3. если есть конфликтующие требования — то нужно их пытатсья разрулить, и вот такие варианты есть как их можно разруливать (ясно, что не стоит просто в лоб пытаться реализовать оба конфликтующих требования, иначе при выкате на прод всё сломается нафиг — а такое может быть если один менеджер дал напрямую одному разработчику одну задачу, а другой менеджер дал другому разработчику другую задачу)
Возможно, в вашей практике, и в вашей работе таких проблем не возникает или вы уже знаете как их решать и успешно решаете более сложные проблемы.
Но я вижу в реальной жизни много людей, которые не делают даже описанного в статье, и видел в своей жизни много компаний, которые даже такие простые проблемы не могли решить или даже не пытались. Это существует в реальном мире.
И я рад что у вас этого нет. Но это не повод не делиться опытом.
У нас например в начале проекта в котором я работаю эти проблемы все были и ни одна из них не была решена. Но постепенно мы их все плюс-минус зарешали, хотя иногда до сих пор бывает что кто-то с квадратными глазами вбегает к разработчику и говорит что нужно срочно сделать новую табличку из которой будет что-то как-то куда-то считаться. И разработчик начинает делать.
И приходится потом бегать, рассказывать что у нас уже есть готовая система, которая уже считает и отдаёт то, что нужно, и выдёргивать из рук разработчика наполовину сделанную задачу )))) Но с каждым разом таких единичных случаев всё меньше и меньше.
Ещё раз повторю, я очень рад, что у вас такого нет и всё хорошо.
Все, все, сдаюсь.
Но если бы вы внимательно читали и думали, о чем я пишу, вы бы заметили: такие проблемы есть у всех, все о них знают, и всем приходится их решать в той или иной степени. И интересно не то, что они есть, а как именно их решаете вы. Методология, алгоритмы, роли в команде и т.п. Рассказ типа «у нас прибегают пользователи с квадратными глазами и спрашивают про что-то, что уже есть… что делать? Рассказать им, что оно есть!» — ну вы поняли:)
Но если бы вы внимательно читали и думали, о чем я пишу, вы бы заметили: такие проблемы есть у всех, все о них знают, и всем приходится их решать в той или иной степени. И интересно не то, что они есть, а как именно их решаете вы. Методология, алгоритмы, роли в команде и т.п. Рассказ типа «у нас прибегают пользователи с квадратными глазами и спрашивают про что-то, что уже есть… что делать? Рассказать им, что оно есть!» — ну вы поняли:)
Ну вот как я написал в статье — так и решаем )
Если говорить за организационные моменты, то это тема интересная. Но в подробностях я её раскрыть не смогу, так как для этого нужно описать чем, как и почему занимается наша компания, как она устроена организационно внутри, и почему именно так. Как это всё работает. И уже потом раскрывать эту тему.
Пока что такой возможности нет. Может быть в другой раз, если по NDA разрешат на какой-нибудь конференции поделиться )
Если говорить за организационные моменты, то это тема интересная. Но в подробностях я её раскрыть не смогу, так как для этого нужно описать чем, как и почему занимается наша компания, как она устроена организационно внутри, и почему именно так. Как это всё работает. И уже потом раскрывать эту тему.
Пока что такой возможности нет. Может быть в другой раз, если по NDA разрешат на какой-нибудь конференции поделиться )
А вообще, вы же можете написать свою заметку с той информацией, которую вы знаете, но которой нет в данной статье, и которая по-вашему представляет ценность для читателей. Для тех людей, которые ещё не знают того, что знаете и на практике применили вы. Я думаю это было бы весьма полезно и интересно.
Дописал в предисловие, какие темы данная статья собирается, а какие не собирается раскрывать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление требованиями к IT-продукту внутри компании