Именно в такой формулировке нам его задают редко, но часто и даже очень часто появляются конкретные вопросы – «почему вы сделали это?», «почему вы НЕ сделали это?», «почему бы вам не сделать это?», «когда вы сделаете это?», «когда же вы, наконец, сделаете это?!!!», …
Попробуем описать то, как мы решаем, что когда делать.
Вообще, есть вполне себе общепринятые процессы управления требованиями.
К сожалению, в основном, они относятся к заказным разработкам, а у нас тиражная. Причем, весьма и весьма тиражная.
К сожалению, в основном, они относятся к более прикладным задачам. А у нас технологическая платформа (фреймворк).
Кажется, что второе обстоятельство, играет меньшую роль в особенностях нашего положения.
Само понятие «требование» кажется (особенно в русскоязычном прочтении) не совсем правильным в нашем случае. Так как у нас нет одного заказчика, который что-то «требует», то все, что мы можем делать (потенциальные «фичи»), можно описать очень разнообразными терминами («пожелания», «предложения», «потребности», «идеи», ….).
У нас так и не сформировалось единого названия для этого предмета.
Чаще всего используем термин «пожелание». Хотя это не всегда точно отражает конкретные случаи.
У нас записаны тысячи (многие тысячи) пожеланий. Безусловно, даже невозможно себе представить, что мы их все когда-либо реализуем. Причем, даже, если не брать в расчет время и трудоемкость, то они все (все вместе) просто не нужны! И, поэтому, постоянно стоит вопрос – а что нужно делать сейчас?! Под «сейчас», конечно, понимаются очень разные временные диапазоны.
Несложно перечислить основные источники – откуда берутся пожелания:
- Пожелания и идеи разработчиков прикладных решений
- Пожелания и идеи партнеров
- Пожелания и идеи пользователей
- Пожелания и идеи руководства фирмы
- Пожелания и идеи других подразделений
- То, что реализовано в каких-то продуктах на рынке (как конкурирующих с нами, так и не конкурирующих)
- То, что вытекает из тенденций развития IT и бизнеса в мире
- Наши собственные идеи
Порядок следования пунктов в этом списке не является отражением приоритетов. Это просто перечисление. Приоритеты определяются более сложным образом. Об этом далее.
У нас нет отдельных аналитиков, которые отбирают реализуемые пожелания.
За выбор реализуемых задачи и направлений развития отвечает команда разработки.
Выбор приоритетов (планирование «фич») сейчас выполняется по командам (раньше это делалось централизованно).
То есть, выбор осуществляется не из общего списка, а из списка команды.
Тим-лид команды, советуясь с членами команды, определяет приоритеты потенциальных задач и формирует план. Разумеется, здесь играет роль периодичность планирования (планирование может вестись по нескольким временнЫм горизонтам), но это отдельная тема.
Сформированный план обсуждается с другими командами, когда это требуется, и с руководством проекта. При этом обсуждении, разумеется, решения могут поменяться.
Мы стараемся, чтобы в команде был постоянный «бэклог» — список потенциальных задач, отранжированных по приоритетам, на 2-3 этапа планирования вперед.
Методика отбора пожеланий в командах может несколько отличаться. На это могут влиять особенности спектра функциональности, за которую отвечает команда, и предпочтения тим-лида команды.
Разумеется, такой подход формирует повышенные требования к тим-лидам команды, архитекторам и разработчикам команды. Они должны понимать, как используется платформа, анализировать пожелания пользователей и разработчиков приложений, следить за тенденциями в IT, понимать направления развития конкурирующих технологий. Здесь под конкурирующими технологиями понимаются не только (и часто даже не столько) конкуренты по бизнесу, сколько имеющиеся и появляющиеся технологии по конкретным направлениям. Например, для UI механизмов платформы – это современные UI-фреймворки, для механизма работы с данными — это универсальные механизмы работы с данными (например, ORM).
Таким образом, получается, что тим-лид и ответственный за некоторый механизм платформы, кроме всех остальных качеств, выполняют и роль аналитика. Хотя именно этот термин мы не используем, но эта часть работы очень и очень важна.
Общие направления развития и наиболее значимые задачи согласуются с директором фирмы.
Директор может как дать рекомендации, так и непосредственно повлиять на решение. Разумеется, при выборе окончательных решений (на уровне команды, руководства проектом, директора фирмы) действует административная субординация. Но на практике это не вызывает проблем, так как в подавляющем большинстве случаев удается достигнуть взаимопонимания (консенсуса) на всех уровнях. А там, где мнения остаются разными (и принимается директивное решение), мнения объясняются и обсуждаются. Поэтому не возникает ощущения «заадминистрированности» принятия решений.
У нас часто (почти всегда) стоит сложный выбор.
Во-первых, выбор между новыми возможностями и развитием существующих.
Тут нет однозначного критерия, это все нужно и ничем нельзя пожертвовать.
Мы стараемся выдерживать баланс. Активно используемая функциональность всегда порождает массу пожеланий по развитию. Мы стараемся выделить то, чего критически не хватает для эффективного использования и то, что может радикально повысить эффективность. Но если реализовывать только то, что просят пользователи и разработчики приложений по развитию существующих возможностей, то «за бортом» останется развитие в стратегических и перспективных направлениях.
Во-вторых, выбор между повышением надежности, производительности и новыми функциями.
Тоже непростой выбор. Конечно, нужно и то и другое.
Мы оцениваем уровень текущих потребностей и стараемся находить разумный баланс.
Сейчас, например, вопросы надежности и производительности имеют весьма высокий приоритет. У этого есть вполне осязаемые причины.
С одной стороны, использование 1С: Предприятия в корпоративной среде постоянно повышает требования к масштабируемости, надежности и производительности. Внедрения становятся все больше и больше (по количеству конкурентных пользователей, объемам операций в единицу времени, объему функциональности, ...). При этом, повышаются и требования к доступности. Сокращаются допустимые технологические перерывы, цена ошибок становится все выше.
С другой стороны, переход к облачной модели также требует повышения масштабируемости и надежности. Массовые программы, рассчитанные на небольшие предприятия при переходе в облако (работая уже не на одном, а на тысячах предприятий) уже требуют совсем другого уровня надежности и масштабируемости.
Кроме того, сейчас замедлился процесс ротации компьютеров. То есть, наша новая функциональность (которая включает много полезных и удобных возможностей), должна работать на компьютерах 6-7 и даже 10 летнего возраста. Это требует от нас также существенных вложений в оптимизацию.
В-третьих, выбор между текущими потребностями и перспективными разработками.
В общем, кажется, очевидным, что, если хочется получить какое-то новое качество или большой новый механизм, то на его реализацию может уйти много времени (месяцы, годы). И при наличии очень важных и очень актуальных сейчас потребностей мы существенные силы вкладываем в перспективные задачи и направления. Возможно, они не так остро нужны сейчас, но если их не делать сейчас, то их не будет завтра и послезавтра. А тогда они уже могут стать критичными.
Например, в свое время нас упрекали, что мы вложили много усилий в создание и развитие веб-клиента, говорили – посмотрите, веб-клиентом 1С пользуются единицы, вкладывайте лучше ресурсы в то, чем пользуется большинство. Но мы считали (и продолжаем считать) развитие веб-клиента очень важным направлением; не имей мы сейчас полноценного веб-клиента – мы бы существенно проигрывали по сравнению с конкурентами, наши продукты не могли бы внедряться там, где наличие полноценной функциональности при работе в браузере – необходимое условие. И этот факт, несомненно, в итоге негативно сказался бы на всех наших пользователях. Зато теперь мы имеем важное конкурентное преимущество. У нас есть и веб-интерфейс, и нативный интерфейс. Причем разработка веб-интерфейса не требует дополнительных усилий (оба интерфейса генерируются платформой на основе одного и того же приложения) и выглядят оба интерфейса практически одинаково.
Также и с современными тенденциями развития IT. Нужно начинать их учитывать заранее, тогда, когда это пользователям будет казаться пустой тратой нашего времени (вместо того, чтобы что-то полезное сделать). Если начать их поддерживать тогда, когда пользователи начнут в голос про них кричать, то будет уже поздно.
Соответственно, наша задача – совместить в разумной пропорции перспективные задачи и направления с удовлетворением текущих потребностей.
Для выбора перспективных направлений плохо действуют типовые методики и подходы к планированию. Но это, наверное, отдельная тема…
В-четвертых, выбор между полученными пожеланиями и новыми идеями.
Например, самые эффектные технологии, которые меняют мир (в IT и не только) появляются не из пожеланий пользователей, а из идей. Например, возьмем офисный софт. Текстовый процессор, в общем, вполне себе очевидный предмет, вытекающий из пожеланий пользователей – «хотим пишущую машинку, но на компьютере». А вот такую вещь, как электронную таблицу, вряд ли кто-то мог пожелать — это чудесное изобретение. И у нас есть достаточно таких примеров, когда мы не брали готовое пожелание или решение, имеющееся в других технологиях, а придумывали и воплощали свою идею. И это давало очень большой эффект. Так, например, родились механизмы обмена данными и распределенных информационных баз и система компоновки данных. Да и сама концепция объектов конфигурации (бизнес-объекты – справочники, документы, регистры сведений и т.д.), являющаяся краеугольным камнем платформы «1С: Предприятие», возникла как идея команды разработчиков.
Мы считаем идеи разработчиков не менее важными, чем полученные пожелания.
Конечно, важно (и мы понимаем эту ответственность), чтобы выбираемые и реализуемые идеи действительно приносили существенную пользу. То есть никакую идею мы не пускаем в дело, пока не поймем, какую пользу она принесет.
Как влияет «срок давности»?
Срок записи пожелания никак не должен влиять на принятие решения.
Часто можно встретить такую жалобу – «это просили еще 5 лет назад, а вы, до сих пор, этого не сделали».
Да, мы считаем, что «просили еще 5 лет назад» — это не аргумент.
Пожелания не образуют ни очередь, ни стек.
Мы считаем, что приоритеты нужно оценивать на каждом этапе на текущий момент времени.
Ситуация очень быстро меняется. То, что было полезно 5 лет назад, сейчас может быть не очень полезно, а может быть даже и вредно.
И, самое главное, выбор нужно ведь делать в сравнении с текущим набором других возможных задач и направлений развития. Причем, именно по состоянию на текущий момент, но обязательно с учетом будущего. То есть мы оцениваем то, что нужно сегодня, завтра и послезавтра.
Если, например, мы что-то не успели реализовать в некотором механизме на текущем этапе, то оставшиеся нереализованные функции не попадают автоматически в план следующего этапа, а рассматриваются на равных с другими потенциальными задачами.
Кстати, если мысленно представить, что мы начнем сейчас методично реализовывать пожелания, полученные 5-10 лет назад, то это будет очень забавно.
В какой мере мы учитываем количество обращений по конкретному пожеланию?
В общем, учитываем. Но это не главный критерий. Это дополнительная информация для выбора приоритета. Мы понимаем, что есть предметы, по которым количество обращений может свидетельствовать о важности пожелания, а есть предметы, где не может или может в очень небольшой степени.
Как влияет трудоемкость задачи?
Учитывается, но совсем не прямолинейно.
Часто приходится слышать – «почему вы не сделали это, ведь это делать пару часов»
Ну, во-первых, часто (даже очень часто) эта оценка со стороны не учитывает реалии разработки. Чтобы полноценно спроектировать небольшое изменение (учесть его влияние в разных ситуациях на разные механизмы системы) часто уходит существенно больше времени, чем собственно на реализацию. Ну и еще важный аспект. Мы не можем позволить себе реализовывать первое пришедшее в голову решение. Потому что механизмы платформы задействуются в сотнях приложений на многие годы.
Соответственно, нужно рассмотреть несколько вариантов решения задачи и выбрать наиболее правильный.
Во-вторых, непонятно, почему собственно нужно выбирать именно то, что сделать проще и быстрее? Кажется, что делать нужно то, что более важно. Опять же представим, что мы будем делать все то, что проще. Что это будет за развитие системы …
Бывает, что небольшую задачу включаем в план потому что ее можно сделать в определенный момент времени, потому, что в этот момент, нужен небольшой таймаут между двумя запланированными задачами. Но это редкие случаи.
Бывает, что при анализе небольшой задачи, которую хотели включать в план, выясняется, что трудоемкость (а иногда и сам масштаб изменений) будет сильно больше, чем ожидалось. В некоторых случаях это может привести к тому, что задача будет исключена из плана. Например, если ожидаемый эффект кажется недостаточно большим при таких затратах усилий или таких существенных изменениях.
Один из применяемых у нас подходов к выбору приоритетов такой:
- Отбираются задачи, которые решают самые острые проблемы, которые сейчас есть у пользователей и разработчиков приложений,
- Отбираются задачи, которые дадут самый большой эффект по улучшению работы (по нашей оценке и оценке тех, с кем мы посоветовались),
- В план включаются «самые-самые» из обеих групп в некоторой пропорции (например, поровну), столько, чтобы по оптимистичным затратам времени успеть в отведенный срок.
Еще мы используем, например, такой подход:
- Выбирается некоторый (первично отобранный экспертным путем) состав пожеланий,
- По каждому пожеланию вписываются оценки приоритета по 5 бальной шкале:
- с точки зрения пользователей,
- с точки зрения разработчиков прикладных решений (наших и партнерских),
- с точки зрения команды разработки платформы.
- Полученные числа суммируются и пожелания упорядочиваются по полученным приоритетам.
Это позволяет учитывать мнения с разных сторон прилавка. У этого прилавка, как минимум, три стороны (пользователи, разработчики прикладных решений, разработчики платформы).
Получается, своего рода кастинг или конкурс.
В котором пожелания, идеи и критичные потребности выстраиваются на подиуме и демонстрируют свою привлекательность. А мы оцениваем их (с учетом мнений пользователей, разработчиков и нашего мнения) и отбираем самые-самые привлекательные. Иногда кастинг включает несколько туров.
Например, сначала из сотни претендентов отбирается 20 финалистов, потом, из 20 отбирается 5 победителей. А остальные остаются в ожидании следующего конкурса.
Кроме, описанных методик и факторов, конечно, есть еще некоторые факторы (более приземленные), которые тоже влияют на планы.
На принятие решений влияет, конечно, текущая ситуация с загрузкой специалистов.
Например, если для двух отобранных по приоритетам задач нужно активное участие одного и того же специалиста, то одну из них приходится откладывать.
Еще, периодически, случаются «срочные вводные». Например, разработчики некоторого браузера решили что-то поменять в требованиях к приложениям. Тут приходится оперативно пересматривать планы. С учетом широкого спектра поддерживаемых платформ (операционных систем, СУБД, браузеров, мобильных операционных систем, …) это, к сожалению, становится не таким редким явлением.
Про автоматизацию.
У нас централизованно и весьма детально автоматизированы процессы реализации задач и работы с ошибками (task-tracking, bug-tracking). С процессом отбора пожеланий сложнее. Мы реализовали в некоторый момент единую автоматизированную систему для отбора и приоритизации пожеланий. Она получилось весьма сложная, но не покрывала реальных потребностей команд разработки.
Сейчас сами пожелания записываются в некоторый реестр, но отбор и приоритизация пожеланий делается не единым инструментом, а по каждой команде отдельно со специфическими методиками и способами автоматизации.
Возможно, мы когда-нибудь вернемся к этому вопросу.
Мы пока не сделали общедоступный публичный список пожеланий.
Это оказалось достаточно сложным делом (не технически, а методологически).
В части сбора пожеланий – мы реализовали механизм сбора идей для пользователей приложений в рамках сервиса 1cFresh.com. Он вполне успешно работает. По платформе там тоже появляется некоторое количество пожеланий (по той части, которая видна непосредственно пользователям), но, конечно, в основном этот ресурс ориентирован на функциональность прикладных решений.
По платформе, зато, мы сделали ресурс для публикации ошибок (http://ift.tt/1xPR3xh). Кстати, тоже оказалось не так просто.
Иногда мы устраиваем целенаправленные опросы на форуме для специалистов по пожеланиям на конкретную тему, чтобы понять текущие мнения по приоритетам. Обычно это мы делаем тогда, когда начинаем планирование по какому-то направлению и ощущаем нехватку информации.
Хотя у нас и нет общедоступного места, где публикуются пожелания, мы их аккуратно собираем со всех возможных источников (с линии поддержки, форумов, общаясь с партнерами, разработчиками и пользователями на семинарах). У нас все записано! :)
Возможно, мы вернемся к вопросу создания публичного ресурса.
При всех имеющихся методиках отбора идей и пожеланий мы видим свою задачу шире. Не просто выбрать из всех записанных пожеланий самое необходимое, а создавать то новое, что принесет нашим разработчикам и пользователям существенную ценность и сделает мир лучше!
Общую цель ведь можно сформулировать, обычно, достаточно просто. Для нас это – создавать лучшую в мире платформу разработки бизнес-приложений.
А вообще, отбор направлений развития и реализуемых функций в нашей ситуации — это весьма увлекательная и сложная задача. Есть много пожеланий. Есть много идей. Хочется сделать очень много! И нужно выбрать тот оптимальный набор, который сделает наш мир лучше в наибольшей степени.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий