Управление требованиями VS Разработка требований. Принципы и инструменты (Денис Бесков, AnalystDays-2012)/Стенограмма — различия между версиями

Возможно это боян, но это то с чем я сталкиваюсь постоянно.
И проблема не в том, что говорится, что это важно или неважно.
Когда я работаю в индустрии, с коллегами или заказчиками, очень часто они произносят такие слова, как «анализ требований», и под этим на самомм деле имеют в виду весь процесс разработки требований.
Наверное вы тоже встречались с этим. 

[[Файл:Управление требованиями VS Разработка требований. Принципы и инструменты (Денис Бесков, AnalystDays-2012).pdf|center|page=4|512px]]

Это исторически, еще лет 20 назад называлось «Requirements Gathering».
Проблема в том, что разные люди, разные профессионалы, рассматривали разные аспекты работы с требованиями.
Конечно, даже если помнить об этом, не нужно, как «grammar nazi», людей постоянно поправлять. 
Нужно помнить о том, что это просто некоторый эвфмемизм, некоторая оговорка, некоторый просто жаргон, который люди используют, чтобы об этом говорить. 
Но важно помнить, что это не одно и то же. Что есть разные деятельности, разные процессы, которых стоит знать, которых стоит иметь в виду, и которых стоит делать по-разному.

[[Файл:Управление требованиями VS Разработка требований. Принципы и инструменты (Денис Бесков, AnalystDays-2012).pdf|center|page=5|512px]]

Давайте немножко поговорим про разработку требований. И это будет тоже в таком режиме — с одной стороны «капитан Очевидность», с другой стороны, пару тезисов я тут вверну.

Текущая версия на 18:14, 1 декабря 2023

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

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

Немного, пару слов, про то, кто я такой. Кто-то из вас со мной сталкивается впервые, многих из вас я знаю, меня всегда радует, что знакомства пополняются новыми лицами, новыми людьми, новыми талантами.

Вот так выглядит план моего рассказа, о чем идет речь. Я не обещаю глубоко уходить в принципы, глубоко уходить в инструменты, но затронем вещи, которые на мой взгляд, чаще всего в индустрии не проговариваются.

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

Кроме того, я менеджер продукта, отвечаю за коммерческий продукт, продвигаемый на рынке США, компанией Comindware. И по теме продуктовой, я работаю с организаторами продукткэмпов, московского и питерского.

Но давайте перейдем все-таки к теме.

Возможно это боян, но это то с чем я сталкиваюсь постоянно. И проблема не в том, что говорится, что это важно или неважно. Когда я работаю в индустрии, с коллегами или заказчиками, очень часто они произносят такие слова, как «анализ требований», и под этим на самомм деле имеют в виду весь процесс разработки требований. Наверное вы тоже встречались с этим.

Это исторически, еще лет 20 назад называлось «Requirements Gathering». Проблема в том, что разные люди, разные профессионалы, рассматривали разные аспекты работы с требованиями. Конечно, даже если помнить об этом, не нужно, как «grammar nazi», людей постоянно поправлять. Нужно помнить о том, что это просто некоторый эвфемизм, некоторая оговорка, некоторый просто жаргон, который люди используют, чтобы об этом говорить. Но важно помнить, что это не одно и то же. Что есть разные деятельности, разные процессы, которых стоит знать, которых стоит иметь в виду, и которых стоит делать по-разному.

Давайте немножко поговорим про разработку требований. И это будет тоже в таком режиме — с одной стороны «капитан Очевидность», с другой стороны, пару тезисов я тут вверну.

Как перейти к созданию требований. Уточню, что речь идет про создание требований при развитии системы. Потому что когда у нас возникают изменения, а изменения возникают в хорошем проекте всегда, их приходится как-то обрабатывать, всерьез, а не из отношения «ну ладно, уж, так и быть, сделаем», а это в общем, и есть жизнь. Жизнь аналитика, когда ты сделал некоторые базовые требования, а потом пошла реальная работа с отзывом от рынка, заказчиков, пользователей, коллег… и ты постоянно с ними работаешь, развиваешь. Поэтому это все называется «создание требований», и здесь очень важен компонент планирования, про который не в первый раз говорят в индустрии, тем не менее, в цикле работы он часто забывается.

Я специально сделал акцент на моделировании и трассировке, потому что можно сделать акцент на создании одного требования, «цикл создания требования», одного требования, «требования к нагрузке». Но чаще всего, команду и заказчика это не интересует, а интересует набор требований к системе. Поэтому требования создаются к некоторым системам, описывает — что? … описывает модель будущего, в очень широком смысле. Модель будущего какого-то продукта, информационной системы, вебсайта, сервиса. Как он будет устроен, как будет выглядеть для потребителя, как он будет работать, как он будет себя вести — снаружи, не внутри.

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

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

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

Мне кажется, что документирование не что-то очень важное. Вот придумать требование, выписать, сформулировать, донести до людей, так, чтобы они взяли на себя все эти требования, согласовать, вот это очень важно. А вот то, что это оформленно в каком-то документе, красивом или некрасивом, «по-ГОСТу» или «не по-ГОСТу» — это не так важно, в большинстве проектов, с точки зрения работы. Поэтому так и так будет цикл создания требований, и в принципе, на что можно было бы опираться, в дискуссиях, чтобы проверить, убедиться… на википедию нельзя опираться — я смотрел там вчера статью — там полное месиво — анализ там ссылается на инжиниринг, какие-то перенаправления там свернуты на менеджмент… в википедии пока там к сожалению хаос. Какой-нибудь человек, который разбирается в механизме википедии, наверное может там что-то поправить, попытаться изменить… Но там не экспертная точка зрения. То, о чем я говорю, скорее изложено в CMMI, это такой свод документов по процессу разработки ПО, и там достаточно хорошее разделение с разработки на управление, но с привязкой на всякие другие области. Поэтому я отсылаю к CMMI только и только потому, что это единственный экспертный такой документ, который мне кажется, имеет к этому отношение.

Вот я понимаю, что большинство этих вещей не вызывают у вас вопросов. Единственное, я скажу, что моделирование, эта такая вещь, которая может с одной стороны кем-то рассматриваться как что-то отдельное, но на самом деле это всего лишь инструмент обеспечения качества требований. Который нужен для того, чтобы понять, что мы ничего не пропустили, с точки зрения полноты требований, это просто способ представления решений, который позволяет эти решения писать более качественно. Поэтому это должно быть частью анализа требований, когда мы пытаемся моделировать, рисовать, визуализировать, в виде контекстов, сценариев, диаграмм, это ни что иное, как детальная часть создания требований.

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

Дальше давайте перейдем к управлению.

Что это такое? По моему пониманию, это прежде всего управление границами проекта, что мы создаем в качестве продукта, какой он имеет состав, выход. Это управление рамками релиза, т.е. внутри проекта, т.е. мы влезаем в проектные релизы, влезаем в итерации кое-где, и назначаем требования на те или иные релизы, смотрим, насколько они реализуются. Если не реализуются, можно переносить между релизами и итерациями.

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

Итого, я хочу сказать, что все эти вещи, которые называются «scope management», «quality management» и так далее — это управленческие функции, за которые ответственность несет менеджер проекта. Это может быть менеджер продукта, в каком-то случае, уполномоченый вице-аналитик и PM, одновременно, который бывает в маленьких проекта. Но главное это то, что это управленческая функция — отвечать за проект, поэтому он отвечает за результаты проекта, за выход проекта и он обладает и этими компетенциями и полномочиями.

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

Давайте посмотрим более детально, что такое управление границами проекта. Это прежде всего ведение реестра поставок, то, что он выпускает. Что в него входит — фактически это некий состав результата продукта, то, что называется «scope management».

Отбор конечных требований из внешних проектов, в проектной разработке такое бывает часто. Допустим, мы делаем какую-то платформу, в которой основные команды делают какие-то продукты, мы какие-то требования от них принимаем, и это функция PMа, что он берет ответственность на себя за реализацию этих требований. Принимаем не только в формате «а вот пришли какие-то новые хотелки, давайте посмотрим, разберемся», а именно — мы принимаем их в проект, мы будем их делать! И дальше договариваемся о том, когда они будут реализованы, с каким качеством.

Это как раз переговоры, между владельцами так скажем, проектов, владельцами участков, и это менеджерская функция. Ну тоже самое с нашими требованиями. Если мы хотим кому-то отдать требование, то не может аналитик пойти в такой проект, сказать «ребята, сделайте такую-то функцию для нас» потому что он не уполномочен чаще всего представлять… фактически быть заказчиком ресурсов, заказчиком работ у другого проекта, это менеджерская функция. Если есть ответственность за участок, то есть и полномочия, и ответственность, и тот ходит и договаривается между участками, с коллегами на других участках.

Рамки релиза. Ну тут достаточно все понятно, т.е. мы назначаем требования на релизы, назначаем требования на итерации. Причем в этом процессе может активно участвовать аналитик, может активно участвовать заказчик, как некий генератор идей и эксперт, и так далее. Ну а реально, тест (?), что эта фича будет сделана, управляет … именно он управляет рамками этого релиза.

Ну и как уже я сказал, остается статус требований — то что делает аналитик, то, что требование проанализировано, что оно документировано, что оно согласовано. Вот именно управление статусом, это такое управление, которое нельзя отдавать PM-у, потому что он зароется в деталях, он не сможет с каждым отдельным требованием работать. ПиЭм вполне себе сможет работать с набором требований, т.е. если ли они в итерации, реализованы, оттестированы или на тестировании. Аналитик должен этут статус для пиэма производить, и фактически переводить статус требований, о том, что вот да, «я считаю, что продукт с таким-то качеством мы можем уже отдавать заказчику» или «передавать в экплуатацию», если это итерационная разработка.

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

И давайте я уточню, почему об этом идет вот этот сыр-бор. У меня все это связано с определенным опытом. В лаборатории Касперского мы нанимали людей, мы строили процесс, давали инструменты, и у нас возник такой сложный момент, или коллапс, когда то, что мы делали, пытались назвать «requirements management», пытались с этим работать, и в какой-то момент поняли, что у нас серьезные проблемы. Почему? Потому что, мы поняли, что управление… , передача требований в другие проекты, согласования собственно требований, с точки реализации и готовности, все это функции пиэма, функции менеджера, на которые мы не можем оказывать влияние. Была такая ситуация, детали проработки матрицы, и я отвечаю за полноту анализа, и у нас аналитики, они пишут требования, свои требования... при этом попытки обзывать себя «менеджером требований», приводила к проблемам такого рода, что аналитик не имеет полномочий, чтобы назначить эти требования на какой-нибудь релиз или отдать кому-то еще. И более того, когда мы пытались описывать свой процесс, в области, которая касается управления, мы поняли, что тоже, описывая эти области, мы описываем не свою работу. Мы выполняем роль процесс-инженеров, которые за офис управления проектами, пытаются внедрить, как им работать. И мы пытались сказать — давайте мы сходим к ним, попытаемся процесс им передать, пусть офис управления проектами вообще озвучит понимание, о том, как они управляют проектами, … вот есть тридцать проектов, по крайней мере крупных проектов, и там везде эти изделия делают по разному — кто по телефону, кто пишет письма, но у них у всех совершенно разная практика, и нет общего представления об этом деле.

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

Поэтому в организациях матричного типа, где есть выделенные роли аналитика и менеджера, попытка аналитика отвечать за управление требованиями чревата тем, что он в некоторый момент упрется в нехватку полномочий. Т.е. все знают, что компании пытаются на этом играть, они нанимают аналитика, на не очень большие деньги, скажем так, есть менеджер проекта, который постепенно от проекта самоустраняется, и аналитику достается все больше менеджерских функций, при той же зарплате, в какой-то момент начинают его ругать, потому что у аналитика часто не хватает какой-нибудь харизмы, давления, уверенности в себе… это я точно знаю, по опыту индустрии. Еще человек перебирает на себя ответственности, он перерабатывает, какие-то политические игры, а реально при этом у него просто нет должных полномочий. Он называется аналитиком, выполняет аналитическую работу, но при этом берет на себя и какую-то менеджерскую работу. Понятное дело, что в большом проекте PM не может все эти управленческие функции нести на себе, поэтому рано или поздно у нас в Каспере появлялся тимлид-аналитик, который помогал ему в этом самом управлении требованиями.

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

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

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

Теперь по поводу принципов, какие принципы хорошо бы знать, потому что об этом не часто пишут в книгах, форумах.

Принципы разработки требований. Часто бывает такое, что начинающие, и не очень начинающие аналитики думают, что их задача — сделать документ. Сделать документ: красивый, понятный, структурный, и все такое прочее. Потом команда читает документ и говорит «ребята, 33 страницы, мы прочитали 17, больше не можем».

А бывает такое, что требование — это то, что должно изложить нам требование заказчика, чтобы заказчик прочитал наши десять страниц и сказал «о!, это то что я хотел!». С одной стороны это правда, но это не единственная сторона. Главная ответственность аналитика, это вывод проектных решений, как будет работать система, и передает ответственность за эти решения каким-то людям. То, что называется согласование. Потому что может быть просто поставил человек какую-то галочку… но с точки зрения психологии этот процесс сложный, человек может не взять при этом на себя ответственность. «А мне тут подсунули черти-что!», «А я не прочитал это…». Поэтому задача аналитика, чтобы человек принял на себя ответственность.

Второй принцип про то, что мы, ну это принцип любого исследования, в том числе научного. Сначала мы исследуем требования вширь, что вообще есть в системе, как вообще устроен процесс, и только потом идем вглубь. Почему? Бывают неадекватные практики, когда берут какую-то фичу, начинают ее прорабатывать вглубь, какую-то модель строить, и так далее. Потом менеджер приходит, и говорит «Ребята, что у с транком, какие фичи будет отгружать?» — выясняется, что одна фича проработана глубоко, идеально, но релиз продукта не сделаешь. Поэтому важно сначала пройти широко, чтобы оценить, в какой из областей стоит копать дальше, глубже, и насколько глубже копать. Потому что копать на одну глубину подряд, скорее всего не нужно — есть вещи, которые более очевидные, простые, есть вещи, которые менее очевидные, и есть вещи более критичные для бизнеса. Поэтому некоторое правило исследования — сначала мы исследуем вширь, потом идем в глубину. Когда мы поняли, что является областью интересов, что является более рискованным, и так далее.

«Ложки нет» — про что это? Это про то, что нет «правильно-неправильно». У нас на форуме uml2.ru часто задают вопрос — «а правильно ли я нарисовал диаграмму?». И можно конечно сказать, что «с точки зрения нотации UML 2/2.1 вот это не совсем правильно». Но с точки зрения практики работы, это вам ничего не даст абсолютно. Потому что правильно то, что помогает в реализации проекта, в росте вашего доверия и так далее. И если есть такое сочетание — то то, что вы делаете — это вам помогает, имеет смысл и т.д. Но вот такого «правильно со стороны» — такого не бывает, потому что всегда есть контекст организации, контекст проекта, который со стороны неизвестен, и со стороны можно оценить только формально — поставлена галочка или нет, есть там плюсик или нет — но это разговор ни о чем.

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

«Меньше — значит лучше» тоже на самом деле касается на самом деле документирования, потому что чем меньше ваши требования, чем более они простые и компактные, тем лучше для всех. Проще для чтения, проще для восприятия, удобней для реализации.

Как может такое быть? Видите последний пункт — «контекст это король»? Ведь есть известная фраза в интернете «Сontent is the king». Т.е. главное — контент, то, что проходит через все продукты, как он выглядит, как он красиво-некрасиво оформлен. Нет, это неважно! Главное — информация, которая помогает достигать своих целей.

В случае аналитики очень важен контекст. Потому что любое требование, которое двигалось и моделировалось, оно живет в контексте. Мы знаем, что за организация, что за клиент, что у него есть, что происходит, какие у людей есть ожидания, какой есть опыт. Приходим мы к людям и говорим, давайте внедрять систему, ну скажем «что-нибудь-такое-для-управления-требованиями». А выясняется, что у них, в течении десяти лет внедряется какой-то оракловый инструмент, поэтому вот так нахрапу, говорить про какой-то свой инструмент нельзя. Поэтому контекст эта та вещь, которая может занимать громадное количество времени аналитика, прежде всего передача контекста, изучение, и всегда любой документ это некий компромисс, между чистотой-простотой изложения и полнотой контекста. Потому что контекстом либо придется жертвовать, либо передавать его отдельно от документа. В этом плане хороший пример Agile, который говорит «ребята, мы документируем самые простые вещи, а остальное обсуждаем устно». Здесь весь контекст — какие истории и как делают, все обсуждается устно, этого хватает для разработки.

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

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

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

Тут ключевой тезис такой. Инструменты разработки требований, тут в том числе рассказывали про HP ALM/PPM, я верю, что это хороший инструмент, это в Касперском внедрялось для управления в целом, в департаменте, система мощная, хорошая, дорогая… она хорошая. Но реально, многим компаниям она просто не по плечу, и не нужна, с точки зрения денег и с точки зрения функциональности. Об этом стоит думать и знать. Потому что когда вы начинаете рабоать с инструментами, очень часто у нас, технократов есть желание взять самый мощный инструмент на рынке, и начать его копать и внедрить. Начать с «левых» лицензий, потом ходить к руководству, «давайте купим лицензии, по тыща долларов каждая». Руководство хватается за голову «ну, что вы делаете»…

Поэтому я рекомендую так. Если вы начинаете работать с требованиями, как разработчик требований, как аналитик, начните с самого простого, начните с «ворда», поймите его проблемы, поймите его ограничения. Потом посмотрите на инструмент, который будет стоить какие-то деньги, больше чем Word. Это уже будет следующий уровень развития, даже не зрелости, а работы с требованиями. К «телелоджикам» и прочим, переходите после владения инструментом более простого класса. Не пытайтесь найти дорогущий инструмент, который потом надо будет еще освоить, причем не только вам, а еще заказчику и все команде. Вот тут есть такие продукты, они неплохо зарекомендовали себя на рынке, а по поводу Wiki можно сказать, есть Jira/Attlasian Confluence, который достаточно зрелый инструмент, тоже такой технократский, но тем не менее, как некий вариант. Есть конечно еще и MediaWiki и прочие системы, но тем не менее.

И давайте посмотрим, чем отличаются инструменты по управлению требованиями. Видите — там был «ворд/гуглдокс», а тут «эксель/гугл-спредшит». Почему? Потому что управление это в первую очередь ведение реестров. Ведение не с точки зрения наполнения, а с точки зрения управления статусами. Аналитик формирует реестр, пятьсот требований каким-то образом, а менеджер потом посматривает, какие требования реализованы, готовы-неготовы. Для компаний, которые масштабны, у которых много проектов, много продуктов, я рекомендую другие инструменты — вот, есть Sharepoint, который мы использовали в Каспере на некоторых проектах, потому что это полноценная учетная система, позволяет вести реестр, позволяет связывать, делать ссылки на что-то, обсуждать. Так что если компания у вас уже вложилась в микрософтовские решения, этого может хватать.

С другой стороны есть интересные решения нишевые, например «Target Process», которые очень интересно работают с требованиями, они очень много вложили усилий, чтобы работа с требованиями стала интересней, полезней и т.п. Там назначение требований на итерации, релизы и т.п сделано очень хорошо, рекомендую посмотреть.

Что же насчет корпораций, вот сейчас пред конференцией, дописал про «HP PPM», вспомнил про него. Все это мощные, хорошие инструменты, подходите к ним, но после простых инструментов, начиная с доски — ведь списком можно и на доске, самый простой вариант, без всякой автоматизации.

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

— Еще десять минут.

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

Вот все мои слова на сегодня, давайте вопросы.

— Михаил Заборов А вот насчет инструментов управления требованиями, почему ты туда не вписал такие системы как Jira/Bugzilla и так далее?

— Смотрите, есть традиционный класс систем, называются issue-tracking, баг-трекинг и прочее. Bugzilla/Jira и все такое прочее. У меня тут такой подход — что если вы работаете в большой компании, внутри неайтишной компании, не айти отдела, то у вас много заказчиков, которые в IT не разбираются. Поэтому в общем случае, работа с Sharepoint-ом проще, чем с каким-нибудь Mantisом, потому что в Mantis слишком много конструкций специфически программистких, терминов… поэтому лучше брать независимое от IT решение, типа Sharepoint. C другой стороны, если у вас наоборот, компания технологичная и айтишная, то лучше брать так называемые наборы, которые умеют не только с багами работать, которые умеют и с требованиями работать, с тестами и прочим-прочим, почему тут стоит «Target Process» и «DevProm». У меня вот такие рекомендации. Понятно, что можно все сделать на экселе, на Access, с каким-нибудь доступом совместном… но я вот рекомендую — либо самый тупой вариант, шарепоинт, либо вот комбинированные решения.

— Что в Sharepoint можно использовать для управления требованиями? Какие… ?

— Sharepoint это реестрово-документальная система. У вас есть реестр записей, у вас есть поля, атрибуты, есть поиск, есть ссылки. Поэтому меняя статус требования, вы управляете требованием.

— Т.е. строит свои кастомные списки и на этих списках … ?

— Да.

— … Входы-выходы… Можете пример привести?

— Допустим, мы делаем какое-то мобильное (?)приложение, и у нас есть у нас есть внешний проект, который рисует нам дизайн. Какие-нибудь иконки и прочее. В принципе, мы можем выкатить без этих иконок, но … И если эти иконки нам не поступят вовремя, то мы срываем сроки выхода. Допустим, мы не спецы в иконках, мы разработчики. По поводу выходов, ну представим мы делаем движок, модуль, который используется в другом проекте. И если мы сорвем свои сроки, большой проект окажется без этого модуля. Им придется объяснять заказчику, почему они сорвали сроки и модуль не работает. Как-то так.

— Вадим Мустяца: Вот разделение на ПиЭма и Аналитика. Чем руководствуется пиэм, управляя требованиями? Все равно он принимает решения, на основе, определенных, скажем так, знаний. Кто ему их предоставляет? Он же не может знать систему настолько детализировано, чтобы принять это решение?

— Да, конечно. Смотрите, у нас пиэм принимает решение о чем? Об объеме продукта, какие фичи будут реализованы, о его качестве, насколько хорошо они будут реализованы — это все он может в диалоге с Аналитиком смотреть, аналитик рассказывает, но возникает еще пара компонентов — время и деньги. Вот по этим вопросам он уже общается с командой, и общается с заказчиком. Заказчик говорит «ну вот у меня есть 100000 долларов, больше ни копейки, поэтому что вы тут написали, давайте это порежем, чтобы уложится в бюджет и успеть». Или с командой — «да, вы все тут молодцы, но нанят новый человек, его будем обучать, поэтому мы не успеем эту фичу реализовать за два месяца, давайте что-то думать». Поэтому пиэм выступает в роли, скажем такого торговца, негоцианта, который торгуется со всеми сторонами, который пытается найти какой-то баланс, по этим пресловутым сторонам треугольника пиэмского. По вопросам качества и обьема он торгуется с аналитиком, выясняя почему они появились, почему пролетели и все такое прочее. И одновременно он еще может общатся с заказчиком, уточняя ситуацию — может аналитик что-нибудь не проверяет и т.п. — может это требование заказчик и не хочет делать дальше.