И снова здравствуйте! Эта статья содержит описание разрешения одного противоречия в управлении требованиями. У меня появилось сразу несколько поводов для написания этой статьи. Во-первых, это дискуссия о трендах развития области управления требованиями, состоявшаяся среди членов сообщества analyst.by. Во-вторых, свежий опыт участия в краудсорсинговом проекте Сбербанка. И в-третьих, эта статья — еще один аргумент для скептиков, кто сомневаются в ценности ТРИЗ для бизнес-анализа.
Проблема управления требованиями
Сегодня уже никого не нужно убеждать, что управление требованиями, в том числе, сбор, анализ, обработка и оценка реализации требований, является необходимой составной частью процесса разработки информационных систем. Важность этих видов деятельности выражается еще и в том, что сегодня управлением требованиями занимаются специально обученные люди – системные и бизнес-аналитики. Кроме аналитиков в той или иной степени требованиями занимаются и другие люди: владельцы продукта (product owners), тестировщики (QA специалисты), «юзабилисты» (UX специалисты и специалисты по интерфейсам), продавцы, маркетологи и многие другие. Не стоит также забывать о руководителях проектов (project managers) и, конечно же, о разработчиках (developers).
Но так было не всегда! В популярной в свое время в ИТ-среде книге Фредерика Брукса «Мифический человеко-месяц. Или как создаются программные системы» повторного издания 1995 года автор рассказывает, что в те почти античные для ИТ-сферы времена уже осознавалась важность управления требованиями, но в книге нет упоминания всех тех специалистов, которые занимаются управлением требованиями сегодня.
В связи с этим обстоятельством возникает несколько интересных, на мой взгляд, вопросов:
1) Какой фактор повлиял на появление всех этих новых специальностей?
2) Продолжает ли этот фактор действовать сегодня?
3) Если да, то каким образом действие этого фактора повлияет на развитие ИТ-сферы в будущем?
Если мы зададим эти вопросы экономисту, то он ответит, что мы наблюдаем естественный процесс углубления разделения труда, связанный, с одной стороны, с ростом сложности технологий разработки информационных систем, а с другой стороны, необходимостью повышения производительности труда в ИТ-сфере. Из этого ответа следует, что нас ожидает в будущем появление новых специальностей, в том числе, связанных с управлением требованиями.
Бизнес-аналитик может предложить другой ответ, определив, какую именно проблему решает появление специальных людей, ответственных за управление требованиями. В ИТ-сфере известен следующий феномен: стоимость внесения изменений в информационную систему тем выше, чем на более поздней стадии проекта такие изменения вносятся. Если, условно, стоимость внесения изменений на стадии технического задания составляет 1 руб., то на стадии спецификаций стоимость будет уже 10 руб.; на стадии разработки – 100 руб., а на стадии внедрения – 1000 руб. Раньше (всего-то 10-20 лет назад) сбором и управлением требованиями, а также управлением изменениями (основной причиной которых являются неточно определенные требования) занимались сами разработчики информационной системы. Для предотвращения экспоненциального роста затрат на изменения на поздних стадиях проектов управление требованиями (и частично изменениями) переложили на плечи аналитиков. Другими словами, появление аналитиков – это способ снижения совокупных затрат на проекты, связанных с управлением требованиями и изменениями.
Однако, мы сталкиваемся с новым противоречием:
Если на ранних стадиях проекта разработки информационной системы требования будут выявляться и анализироваться точнее, то мы можем добиться снижения затрат, связанных с внесением дорогостоящих изменений на поздних стадиях проекта, но при этом нам потребуется включить в проект специальных людей (аналитиков), которые будут заниматься управлением требованиями. Это приводит к усложнению управлением проекта, в том числе, усложнению коммуникаций между участниками проекта.
Как быть?
На первый взгляд, в каждом проекте мы можем достичь определенного баланса между точностью управления требованиями и размером проектной команды, а также связанной с этим сложностью управления проектом. Этот баланс находится где-то между затратами на изменения, связанные с ошибками в управлении требованиями, и затратами на управление проектами. Можно даже придумать уравнение баланса с большим количеством переменных, описывающих аналитические, девелоперские и коммуникационные навыки членов команды и тому подобное.
Однако те из вас, кто познакомился с Обзором ТРИЗ для системных и бизнес-аналитиков, уже догадались, что может быть найдено решение проблемы управления требованиями, устраняющее указанное выше противоречие.
В нашем случае в качестве идеального конечного результата должен выступать неизвестный пока Х-элемент, который с высокой точностью обеспечит выявление, анализ, оценку требований на ранней стадии проекта по разработке информационной системы, при этом не потребует привлечения в команду проекта большого количества аналитиков и усложнения системы управления проектом.
Мы опускаем описание хода анализа противоречия, как и этап синтеза решения для Х-элемента, поскольку это не является предметом данной статьи.
Одним из возможных кандидатов на роль Х-элемента являются пользователи информационной системы: пользователи информационной системы сами выполняют функции по определению, анализу и оценке требований.
Решение уже существует!
Сегодня уже существуют технологии, которые позволяют реализовать требования, определенные для Х-элемента.
Краудсорсинг (англ. crowdsourcing, crowd — «толпа» и sourcing — «использование ресурсов») — передача определённых производственных функций неопределённому кругу лиц. Решение общественно значимых задач силами множества добровольцев, часто координирующих при этом свою деятельность с помощью информационных технологий.
Краудсорсинг – это главный управленческий прорыв XXI века
Герман Греф
Широко известным примером успешного применения технологии краудсорсинга является проект свободной энциклопедии Wikipedia. Свежий пример – применение краудсорсинга для развития Сбербанка России.
На сегодняшний день известно большое количество платформ, обеспечивающих поддержку технологий краудсорсинга. Краткий обзор таких платформ можно посмотреть здесь.
Краудсорсинговые технологии не являются чем-то принципиально новым и для ИТ-сферы. Достаточно вспомнить технологию бета-тестирования информационной системы, суть которой состоит в привлечении большого количества пользователей для тестирования почти готовой системы.
Крауданализ
Краудсорсинговая платформа позволит привлечь большое количество пользователей разрабатываемой информационной системы, где они смогут высказываться о своих потребностях и предпочтениях.
На платформе можно предложить пользователям формулировать свои требования, заполняя определенные шаблоны, например «система название_системы должна выполнять функцию название_функции каждые единица_времени». Заполняя шаблоны, пользователи будут предоставлять требования в уже структурированном виде.
Пользователи на платформе могут голосовать, устанавливая приоритеты для сформулированных требований.
Пользователи смогут отслеживать реализуемость требований, например, путем выставления оценок типа «насколько полно реализовано данное требование».
Пользователи смогут общаться на платформе друг с другом, обсуждать требования, генерировать новые идеи, оценивать друг друга и накапливать социальный капитал.
Краудорсинговая платформа позволит коллективно решать возникающие по ходу разработки проблемы, устраивать мозговые штурмы с участием большого количества людей.
Применение краудсорсинговой платформы кардинально изменит отношение пользователей к будущей информационной системе. Принимая участие в проектировании, пользователи будут рассматривать новую информационную систему как родную: бета-тестирование станет органичной частью процесса разработки; значительно сократятся или исчезнут совсем проблемы внедрения и обучения пользователей.
Очевидно, что применение краудсорсинговой платформы не исключает роль аналитиков; однако, роль аналитиков в проекте претерпит значительные изменения. Аналитикам не нужно будет встречаться с пользователями, проводить интервью, согласовывать документы с пользователями. Аналитики должны будут модерировать работу пользователей на платформе, формулировать задания, готовить для пользователей обзоры по различным темам, касающимся области применения информационной системы. Естественно, аналитики будут анализировать требования, сформулированные пользователями, и превращать их в документы для разработчиков информационной системы.
Можно также предположить, что применение технологий краудсорсинга для управления требованиями приведет к изменению бизнес-моделей, по которым сегодня организована работа ИТ-компаний. Однако это уже тема для отдельного разговора.
По-моему, это нужно было везти на REQ Labs, а не увозить оттуда )) Честно признаться, изначально я планировал рассказывать именно о краудсорсинговом сборе требований через Риззому. Но потом планы немного изменились +)
Абсолютно согласен, что за этим будущее. Команда Rizzoma уже сейчас использует подобный механизм и мне неоднократно приходилось становиться участником процесса. Работает!
Вадим!
Я уверен что это работает. Я недавно участвовал в краудсорсинговом проекте Сбербанка и изучал технологию с точки зрения «одного из толпы». Конкретно в этом проекте у увидел ряд технических проблем, требующих решения, но в целом впечатления — позитивные.
Но меня интересует не столько техническая сторона дела, и даже не столько встраивание краудосорсинговой платформы в конкретные проекты, сколько то, как это повлияет на бизнес-модели ИТ-компаний. Было бы здорово, если бы ты поделился своими соображениями об этой стороне применения краудсорсинга. Может, в виде статьи для analyst.by ? ;)
Тема, безусловно, перспективная, я подумаю ))
У меня была одна идея технической реализации путём совместного использования возможностей Rizzoma и Trello.
В частности, «голосование» за истории можно реализовать путём перетаскивания их карточек из одного состояния в другое на доске задач. Система учитывает все перемещения, валидирует их и выдаёт на доске команды конечный результат )
Если к этому всему прикрутить ещё и effectcup, где истории будут генерироваться, можно создать поистине выдающийся продукт!
Риззомовцы, кстати, используют очень крутой сервис поддержки клиентов, который работает по схожей с описанной в статье модели: https://getsatisfaction.com/rizzoma
Пользователи могут оставить как ошибку или вопрос, так и идею для продукта. Таким образом, возникают истории, исходящие напрямую от заинтересованных лиц. Сам частенько туда идейки подкидываю ))
Ах, да, можно ещё похвалить разработчиков, что тоже весьма немаловажно )))
Андрей, я знаю такой кейс. Одна из частей IBM WebSphere разрабатывалась именно так: разработчики забили на бэклог и работали полностью исходя из пожеланий пользователей.
Мэри Поппендик как-то об этом рассказывала.
Но я вижу тут определенную опасность: если пользователи будут говорить нам, как делать продукт — не получится ли продукт, решающий проблемы пользователей вместо того, чтобы достигать целей бизнеса?
Артем,
если заменить слово «пользователи» словом «стейкхолдеры», то проблемы в том виде, в котором ты ее сформулировал, не будет. Требования будут вырабатываться с учетом всех заинтересованных сторон.
Другое дело, что мы будем постоянно сталкиваться с противоречиями между требованиями разных заинтересованных сторон. Ну, дык мы же знаем, как обходиться с противоречиями! :)
P.S. Спасибо за ссылку!
Краудсорсингом собираются первичные требования, а в разработку идут валидированные требования к продукту, так что опасность эта существует лишь в таких экстремальных случаях, как в примере с IBM )
В сущности, крауд может оптимизировать два процесса: сбор первичных требований и управление валидированными требованиями (точнее учёт мнений пользователей при таком управлении).
Вадим,
я бы рассматривал весь жизненный цикл требований, включая тестирование и оценку реализации. Тем более, что бета-тестирование можно рассматривать как вариант краудсорсинга.
Да, конечно, я говорил лишь применительно к требованиям.
Кстати, удалите в Твиттере лишние публикации со ссылками на эту статью, а то их получилось целых три )
Вадим, спасибо! Удалил.
Как это выглядит?
Человек, который «не в теме», и человек, который «в теме», напишут по одному требованию. 10 человек поставят «лайки» на требование человека, который «не в теме». (Ну или как-то так.) В итоге правильное требование будет проигнорировано.
Если вы знаете, какое требование правильное, а какое нет, то зачем нужен опрос?
Не-не, до голосования доходят лишь провалидированные требования, которые по определению не могут быть от человека «не в теме». К тому же, конечное решение всё равно остаётся за продактом и командой, вся эта игра с голосованиями нужна лишь для понимания мнения пользователей и принятие его во внимание во время приоритезации.
Хотя, чего далеко ходить, на том же https://getsatisfaction.com/rizzoma голосовать можно за любой топик (ошибку, вопрос, идею, похвалу), но всё это используется лишь для информирования команды о воле народа +)
Далеко не все топовые предложение берутся в работу, это я знаю наверняка ))
Ну так и какой в этом смысл? Повысить самооценку незначимым сотрудникам? :)
То, что я буду знать мнение пользователей, это не только не гарантирует создание правильных требований, но и, возможно, наоборот, направит внимание всей команды разработчкиков на неправильную цель.
Например, есть какая-то форма. 100500 пользователей проголосовало за изменение этой формы. Результат: команда разработчиков незаметила возможность вообще отказаться от этой формы.
По-моему, тема краудсорсинга в постановке задачи имеет смысл делать только среди узкого круга ответственных работиков. В противном случае это, как ты правильно заметил, не более чем игра, в которую со временем народ перестанет играть. А зачем играть, если тебя не замечают. :)
Если 100500 пользователей проголосовало за изменение формы, значит на форму нужно обратить внимание, что-то с ней не так. Но устранение этого «не так» далеко не обязательно будет соответствовать запрошенным пользователями изменениям. Вот и вся логика.
Алексей,
вы считаете, что аналитик лучше знает правильные требования, чем пользователь «не в теме» и еще 10 других пользователей, которые поставили ему лайки? А откуда он это знает?
И еще один вопрос: каков, по вашему, критерий правильности требования?
(Можно на «ты».)
Мы говорим об аналитике «с улицы», который впервые слышит об автоматизируемой области, или об аналитике, который знает «мировые практики», знает как автоматизированная область контактирует с другими областями и, собственно, неплохо знает эти контактируемые области?
Если аналитик не знает этого, то он не намного лучше одного из 10 пользователей, который, возможно, не видит дальше своего рабочего места.
Тогда давай говорить не об аналитике, а о требованиях.
Ты говоришь, что есть требования общеизвестные, установленные мировыми практиками и т.д.
Отлично, что мешает сформулировать их и дать возможность пользователям оценить эти требования, определить их важность?
Ведь мировые практики устаревают; даже супер-пупер аналитик физически не в состоянии отслеживать все эти изменения, тем более, изменение важности этих требований для пользователей. В конечном счете, аналитику все равно потребуется услышать «голоса пользователей», провести с ними интервью, опросы и т.п.
Еще один класс требований — это требования, которые пока еще не стали частью лучшей мировой практики, но уже посетили головы отдельных пытливых пользователей. Для извлечения этих требований недостаточно опытного аналитика; требуется знание той ситуации, в которой находится такой пользователь. Не секрет, что среди таких требований попадаются истинные алмазы.
Другими словами, проблема извлечения требований не сводится к компетенции аналитика. Требуется еще большой объем рутинной работы. Здесь уместна аналогия с геологоразведкой. Опытный геолог может оценить вероятность нахождения месторождения полезных ископаемых, исходя из имеющихся у него знаний. А местный житель, не имеющий представления о геологии, найдет блестящий камешек, который окажется слитком золота.
Если требования уже сформулированы, то краудсорсинг и подавно не нужен. :)
Устаревание требований — не слышал о таком. Например, требования для (автоматизации) документооборота MoReq имеют всего две версии, причём последняя — от 2008 года. :) (Хотя вру: погуглил, вроде как ещё от 2010 года есть, но это не сильно что-то меняет.)
С «алмазами» соглашусь, но алмазы — это такая редкость, что их поиск может не только не окупиться, но и потратит время. А все «местные жители», которых я знаю, приносили мне максимум «дерево». ;)
Кстати, «алмазы» я искал не у заказчика, а в интернете — это было гораздо эффективнее.
Кстати, очень удачное сравнение аналитика с геологом. Мне пришло в голову, ещё когда читал Лезвие бритвы Ефремова. Много общего у профессий +)
Сегодня наткнулся в ленте: https://plus.google.com/+GoogleScienceFair/posts/8uT4yAPjzxK ))
Hola!
статья интересная, мэй би это станет тенденцией в отрасли Б-А для разработки ИТ-систем. Понятно, что если будет так, то к навыкам Б-А добавится умение модерировать дискуссии. А, может быть, (я в тайне надеюсь) Б-А освоят когда-нить QFD. и в купе с краудсорсингом это даст существенный прирост пользы от труда представителей этой профессии )
Макс, не мог бы ты опубликовать полезные ссылки на QFD ?
http://www.twirpx.com/file/408827/
Коллега, сенкс за ссылку )
кроме указанной Костей книги, говорят, что эта книга будет полезна: http://www.amazon.com/Quality-Function-Deployment-Sigma-Second/dp/0135138353/
Алексей, отвечаю в отдельной ветке.
Ты написал: Если требования уже сформулированы, то краудсорсинг и подавно не нужен. :)
Давай посмотрим на весь жизненный цикл требования. Если по верхам, то это
1. Выявление
2. Формулировка
3. Установка приоритета
4. Маппинг на решение (и верификация)
5. Реализация в решении
6. Оценка реализации (валидация)
7. Обнаружение отклонений и недовольств и переход к п.1
Даже если мы имеем дело с уже сформулированными требованиями, для краудсорсинга остается еще много точек приложения.
По-любому, валидацию требований (6) и формулировку своих недовольств (7) делают потребители.
Для того, чтобы эти недовльства предвосхитить, имеет смысл привлечь пользователей на ранние стадии ЖЦ требований, т.е. на этапы (1 — 3) и даже на (4).
Так что не могу согласиться с тезисом, что для краудсорсинга нет места.
Если на этапах 6 и 7 пользоватили проявили недовольства, то либо это недовольства по реализации (тогда можно переходить к пункту 5), либо это недовольства по пунктам 1-3, что показывает, мягко говоря, что опрос пользователей не дал нужного результата. Если у нас «водопадная» разработка (например, по ГОСТу), то это финиш. Если мы работаем по какому-нибудь «аджайлу», то делаем транзакцию в кошелёк заказчика. :) Что как бы тоже не супер. Где я тут не прав?
Что происходит в пункте 4?
И да, я всегда общался с пользователями на первых и последних пунктах. (Специфика внедряемых мной систем.) Но это была только ограниченная группа сотрудников, которые «в теме».
Алексей, все правильно. Но ведь в том-то и дело, что при увеличении количества аналитиков неизбежен рост ситуаций, когда «опрос пользователей не дал нужного результата». Классическая ситуация: чем больше команда, тем больше вероятность ошибок, недоработок. Крауданализ как раз разруливает эту проблему.
В п. 4 происходит подбор решений, удовлетворяющих требованиям. Например, в виде совещаний аналитиков с разработчиками. Здесь часто выясняется наличие между требованиями противоречий.
Ну, я вижу, что ситуация в точности наоборот. :)
Кстати, не знаю причин, но у нас никогда не увеличивали команду аналитиков, и которая состояла максимум из двух человек, и заказчики были очень крупные. :)
Интересный материал. Но Вам не кажется, что »краудсорсинг» в данном контексте это лишь новое название для старых инструментов, многие из которых существуют уже более 50 лет. Раньше я бы назвал это «провести фокус-группы на этапе генерации идей мозгового штурма». И если правильно понял материал, краудсорсинг в данном случае никак не снижает затраты на аналитику (не упрощает управление). Это дополнение к стандартной работе, а значит увеличивает затраты и сложность управления. Если же придумано как заменить краудсорсингом работу аналитиков, то в этом основной секрет, который в статье не описан. Если не считать голословного утверждения «пользователи информационной системы сами выполняют функции по определению, анализу и оценке требований.»
Вот качество аналитики может стать существенно выше.
Константин,
если вернуться к исходному противоречию, то оно как раз и демонстрирует, что для повышения точности работы с требованиями требуется привлекать на проекты все большее количество аналитиков. Так, если сегодня на небольших проектах работают 1-2 аналитика, то на сложных проектах уже задействованы по несколько команд аналитиков (услышал в одном из докладов на ReqLabs-2012). Следуя тенденции, завтра потребуется еще больше аналитиков.
Краудсорсинговая технология «ломает» эту тенденцию. Не надо увеличивать количество аналитиков, надо изменить их функции. Некоторые функции мы можем переложить на пользователей: формулировка требований, оценка, контроль реализации. Функция аналитика здесь — организовать работу пользователей, модерировать «толпу». В этом случае 1-2 аналитика + «толпа» могут заменить большую команду аналитиков. Именно здесь происходит «отвязка» затрат от функций. Затраты остаются фиксированными: 1-2 аналитика. А количество работы с требованиями может масштабироваться в зависимости от количества привлеченных краусорсеров и интенсивности их участия в проекте.
Принципиальное отличие от упомянутых вами старых технологий состоит в том, что в отличие от пассивного пользователя краудсорсер активен. У него есть (должны быть) возможности активно влиять на содержание проекта. В идеале, краудсорсер полностью сопровождает требование по всему жизненному циклу в проекте. Как-то так!
Спасибо, идея стала понятнее. Тогда желательно сравнение по деньгам: сколько стоит добавить 1 аналитика (команду) и сколько стоит организовать краудсорсинг для разных масштабов проекта. А то «краудсорсинг» звучит дорого. Кроме самого модерирования необходима разработка методологии модерирования, создание определенной инфраструктуры. Кроме того, пока звучит так, что управление проектом станет сложнее, а не проще. Ведь краудсорсеры могут вообще ничего не делать и даже вредить, а инструментов влияния на них мало :)
Константин,
кто ж сейчас знает, сколько ЭТО будет стоить? :-) Пока это только идея!
Но я вижу уже сегодня много интересных областей применения.
Если говорить о том же Get Satisfaction, то стоит это https://getsatisfaction.com/corp/smallbusinessforum/index + та оплата той части времени сотрудников компании, которые занимаются модерированием.
Андрей, далеко не идея.
Многие компании-разработчики позволяют пользователям создавать тикеты различного рода. Возьми ту же Мозиллу.
Вадим уже не раз привел пример getsatisfaction — я тоже его юзал, чтобы подкинуть разработчику идей по продукту.