Sape plugin info: test sape ok

Целью данной статьи является ответ на один вопрос:

Как мы решаем, что и когда внедрять в платформу «1С:Предприятие»

Мы редко слышим такую точную формулировку, а вопросы типа «Почему ты это сделал?», «Почему ты НЕ сделал этого?», «Почему ты не сделал этого?», «Когда ты собираешься это сделать?» », «Сделаешь это когда-нибудь или нет?!!!» и так далее, всплывают снова и снова.

Хорошо, давайте попробуем объяснить, как мы решаем, что делать

Конечно, существуют общепринятые требования к процедурам управления.

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

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

Похоже, последнее не так важно, как первое

Само понятие «требование» в нашем случае кажется не совсем правильным. Поскольку у нас нет ни одного конечного потребителя 1с битрикс управление сайтом стандарт, которому что-то «требуется», все, что мы делаем (потенциальные возможности), можно описать очень разными терминами (пожелания, предложения, потребности, идеи и т. д.).

У нас до сих пор нет единого названия для этого

Чаще всего мы используем термин «предложение», хотя в некоторых случаях он не совсем подходит.

У нас записаны многие тысячи предложений. Невозможно даже представить, что мы когда-нибудь их все реализуем: это не только долго и трудоемко, но и просто не нужно все вместе! Поэтому мы всегда спрашиваем себя: что именно нам сейчас делать? И «сейчас», конечно, означает множество разных временных диапазонов.

Также довольно просто перечислить источники подобных предложений и идей:

Разработчики программного обеспечения
Партнеры
Пользователи
Корпоративное управление
Другие подразделения

Что-то реализованное в других продуктах на рынке (которые не обязательно могут конкурировать с нашими)
Что бы ни исходило из мировых тенденций развития ИТ и бизнеса
Наши собственные идеи
Последовательность пунктов в списке не отражает наши приоритеты, это просто перечисление. Приоритеты определить сложнее, о них речь пойдет позже.

У нас нет аналитиков, сосредоточенных только на выборе предложений для реализации

Команда разработчиков выбирает задачи, которые необходимо решить, и определяет направление нашей работы.

Приоритеты

Сейчас приоритеты выбираются (фичи планируются) на уровне команды (хотя раньше это было централизованно).

Общего списка, из которого можно выбирать, не существует. Вместо этого мы используем список команд.

Руководитель группы обсуждает приоритеты с членами команды, определяет потенциальные приоритетные задачи и создает план. Естественно, важна периодичность планирования (временных горизонтов планирования может быть несколько), но мы не будем здесь вдаваться в подробности.

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

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

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

Конечно, это предъявляет очень высокие требования к руководителям команд, архитекторам и разработчикам команд. Им необходимо понимать, как используется платформа, анализировать предложения пользователей и разработчиков приложений, следить за тенденциями в сфере ИТ и понимать развитие конкурирующих технологий. Конкурирующие технологии – это не обязательно технологии, разработанные бизнес-конкурентами (а очень часто это не так), а существующие и новые технологии в определенных областях. Например, если мы говорим о технологиях пользовательского интерфейса для платформ, нам необходимо обратить внимание на современные UI-фреймворки, а в сфере обработки данных важны универсальные технологии обработки данных (такие как ORM).

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

Как мы выбираем, что внедрять

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

Мы часто сталкиваемся с трудным выбором.

Прежде всего , мы должны сделать выбор между внедрением новых возможностей или развитием существующих.

Не существует четкого правила: все необходимо и не может быть принесено в жертву.

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

Во-вторых , нам предстоит сделать непростой выбор между повышением надежности и производительности

или добавлением новых функций. Конечно, они нам нужны все.

Мы анализируем текущие потребности и пытаемся найти оптимальный баланс.

Например, надежность и производительность являются в настоящее время вопросами высокого приоритета. Это имеет ряд существенных причин.

С одной стороны, использование «1С:Предприятия» в корпоративных средах постоянно предъявляет требования к масштабируемости, надежности и производительности. Развертывания становятся все более сложными (по количеству одновременно работающих пользователей, операций в единицу времени, объему функциональности и т. д.). Требования к доступности также растут. Приемлемое время технологического простоя сокращается, а цена ошибки возрастает.

С другой стороны, появление облачной модели также требует повышения масштабируемости и надежности. Массовые приложения SMB переносятся в облако (где их используют тысячи предприятий вместо одного) и требуют совсем другой надежности и масштабируемости.

Кроме того, сейчас замедлилась ротация ПК. Поэтому наш новый функционал (включающий в себя множество полезных и удобных функций) должен поддерживаться ПК 6, 7 и даже 10-летней давности. Это требует значительных инвестиций в оптимизацию.

В-третьих , нам приходится выбирать между текущими потребностями и перспективными разработками.

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

Однажды нас упрекали в том, что мы вкладываем слишком много усилий в разработку веб-клиента. Критики говорили: «Посмотрите, веб-клиентом 1С пользуется так мало пользователей! Инвестируйте в то, чем пользуются многие». Однако мы считали (и видим сегодня) разработку веб-клиентов жизненно важной областью развития; если бы у нас сейчас не было полнофункционального веб-клиента, мы бы значительно отстали от конкурентов и не смогли бы развертывать наши продукты в средах, где полная функциональность браузера является обязательным условием для развертывания. Это, конечно, негативно повлияет на всех наших пользователей. К счастью, теперь у нас есть большое конкурентное преимущество. У нас есть и веб-интерфейс, и нативный интерфейс, и разработка этого веб-интерфейса не требует особых дополнительных усилий (оба интерфейса созданы платформой на основе одного и того же приложения, поэтому выглядят одинаково).

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

Поэтому наша главная задача – найти идеальный баланс между перспективными задачами и направлениями развития и удовлетворением текущих потребностей.

Стандартные методы и подходы планирования малоэффективны, когда необходимо выбрать перспективные области развития. Но это, наверное, отдельный вопрос…

В-четвертых , нам нужно выбирать между полученными предложениями и новыми идеями.

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

Мы считаем, что идеи разработчиков так же важны, как и предложения, которые мы получаем.

Естественно, выбранные и реализованные идеи должны быть полезными, и мы несем за это ответственность. Мы не поддаемся идее, пока не поймем, чем она может быть полезна.

Время важно?

Время регистрации предложения не должно влиять на принятие решения.

Люди регулярно жалуются, что просили что-то 5 лет назад, а это до сих пор не реализовано.

Мы считаем, что «просили 5 лет назад» — не аргумент.

Мы не ставим предложения в очередь и не накапливаем их.

Мы считаем, что приоритеты должны оцениваться на каждом этапе в режиме реального времени.

Ситуация стремительно меняется: то, что было полезно 5 лет назад, сегодня может оказаться бесполезным или даже вредным.

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

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

Кстати, было бы весьма забавно, если бы именно в этот момент мы начали методично реализовывать запросы, полученные 5-10 лет назад.

Учитываем ли мы количество запросов, связанных с определенным предложением?

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

Учитываете ли вы сложность задачи?

Да, но прямой корреляции нет.

Мы часто слышим что-то вроде: «Почему ты этого не сделал? Это займет всего пару часов».

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

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

Кстати, почему именно нам следует выбирать то, что проще и быстрее реализовать? По нашему мнению, нам следует поработать над наиболее важными функциями. Представьте на секунду, что мы реализовали только самые простые вещи. Система была бы мусором.

Мы можем включить в план второстепенную задачу, потому что ее можно выполнить в определенное время, потому что в данный момент нам нужен тайм-аут между двумя запланированными задачами, но это редкий случай.

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

Иногда мы используем следующий подход для выбора приоритетов:

Мы подбираем задачи для решения самых острых проблем пользователей и разработчиков.
Выбираем задачи, которые дадут наибольший оптимизационный эффект (используем собственную оценку и оценку тех, с кем консультировались).
Задачи с наивысшим рейтингом из обеих групп мы включаем в определенной пропорции (например, в равных частях) в объеме, который позволит уложиться в срок при оптимистическом сценарии.
Другой подход, который мы используем, заключается в следующем:
Выбираем определенный (изначально выбранный экспертными процедурами) список предложений.

Их приоритет мы оцениваем по 5-бальной шкале:

с точки зрения пользователей
с точки зрения разработчиков прикладного программного обеспечения (как наших, так и партнеров)
с точки зрения команды разработчиков платформы

Числа суммируются, а предложения ранжируются по приоритету

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

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

Например, мы можем взять сто вариантов и составить шорт-лист из 20, а затем из этих 20 выбрать 5 победителей. Остальным придется подождать до следующего конкурса.

Конечно, есть и другие факторы (более приземленные, так сказать), которые влияют на наши планы.

Текущая загруженность нашего персонала – одна из них.

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

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

Что касается автоматизации…

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

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

Возможно, мы вернемся к этому вопросу в будущем.

На сегодняшний день у нас нет общедоступного публичного списка предложений.

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

Что касается сбора предложений, то мы реализовали инструмент сбора идей для пользователей приложения на базе сервиса 1cFresh.com. Это работает довольно хорошо. Есть ряд предложений по платформе (фронтенд-части), но, конечно, в основном это касается функциональных вопросов.

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

Поскольку у нас нет общедоступного ресурса для публикации предложений, мы тщательно собираем их из разных источников (включая службы поддержки, форумы, общение с партнерами, разработчиками и пользователями во время семинаров и т. д.). У нас все это записано!🙂

Возможно, мы вернемся к идее создания публичного ресурса.

Существующих методов отбора идей и предложений множество, но мы не хотим ограничивать ими нашу миссию: мы не хотим просто выбирать наиболее необходимые из всех записанных предложений; скорее мы хотим создать что-то новое, что принесет большую пользу нашим разработчикам и пользователям и сделает мир лучше.

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

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