Как мы решаем «Что делать?»

    В статье ответим только на один вопрос – как мы решаем, что и когда реализовывать в платформе «1С:Предприятие».

    Именно в такой формулировке нам его задают редко, но часто и даже очень часто появляются конкретные вопросы – «почему вы сделали это?», «почему вы НЕ сделали это?», «почему бы вам не сделать это?», «когда вы сделаете это?», «когда же вы, наконец, сделаете это?!!!», …

    Попробуем описать то, как мы решаем, что когда делать.



    Требования или пожелания?


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

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

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

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

    Несложно перечислить основные источники – откуда берутся пожелания:
    • Пожелания и идеи разработчиков прикладных решений
    • Пожелания и идеи партнеров
    • Пожелания и идеи пользователей
    • Пожелания и идеи руководства фирмы
    • Пожелания и идеи других подразделений
    • То, что реализовано в каких-то продуктах на рынке (как конкурирующих с нами, так и не конкурирующих)
    • То, что вытекает из тенденций развития 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. Он вполне успешно работает. По платформе там тоже появляется некоторое количество пожеланий (по той части, которая видна непосредственно пользователям), но, конечно, в основном этот ресурс ориентирован на функциональность прикладных решений.

    По платформе, зато, мы сделали ресурс для публикации ошибок (https://bugboard.v8.1c.ru). Кстати, тоже оказалось не так просто.

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

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

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

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

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

    А вообще, отбор направлений развития и реализуемых функций в нашей ситуации — это весьма увлекательная и сложная задача. Есть много пожеланий. Есть много идей. Хочется сделать очень много! И нужно выбрать тот оптимальный набор, который сделает наш мир лучше в наибольшей степени.
    57,00
    Делаем средства разработки бизнес-приложений
    Поделиться публикацией

    Комментарии 23

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

      Некоторые фичи, например, всякие полезные вкусности для IDE (Конфигуратора) висят уже кучу лет и не устаревают.
      Фактически многие вещи, внедренные или внедряемые сейчас в Конфигуратор, запрошены еще лет 10-12 назад :)
        0
        Когда скроете "отказ от модальности" с глаз обычных разработчиков конфигурации?
          0
          А как вы себе это представляете? Ну то есть, что именно (и как именно) должно быть скрыто?
            0
            Платформа "в браузере" (или ради чего у нас вышел отказ от модальности) заработала сама, без изменения "синхронного" кода на на встроенном языке. У "визуальных синхронных" (например Вопрос()) методов появился доп. параметр: "блокировать окно владельца", у "невизуальных" ничего дополнительного не появилось.
            Сейчас это какая-то "синтаксическая горечь" получается, профита ноль, а простейший код типа обхода коллекции (по пути взаимодействуя с пользователем) с постобработкой, или там, рекурсивного обхода каталогов (на клиенте) превращается в спагетти.
            Мелочи типа своей кнопки вместо стандартной, чтобы задать вопрос в "записать и закрыть" уже всем приелись.
            Дополнительно появилась куча экспортных методов форм.
            Появилась невозможность писать одинаковые алгоритмы с использованием невизуальных, но синхронных методов для клиента и для сервера.
            Куча всякого, в общем. И если с приходом управляемых форм (который принес много вопросов, некоторые из которых не закрыты до сих пор) мы получили много новых возможностей, то с "отказом от модальности" новых возможностей нет, или они элементарно добавляются без глобального оспагечиванияпереписывания алгоритмов.
              0
              "синтаксическая горечь" — отличный термин для данной ситуации, записал в словарик. :)
              А визуальность методов тут не при чем. Просто теперь все блокирующие поток выполнения API должны стать асинхронными. Тут речь не только про UI в-общем то. А вот то, что не появилось своего рода async/await это, конечно, несколько грустно. Синтаксическая горечь, ага.

              ну если представить себе pure C с процедурным подходом, то там примерно то же получится. Слабое утешение, конечно, но хоть какое-то)

              Пример с обходом коллекции и интерактивным взаимодействием он в принципе не может быть таким же, как в синхронном режиме, ибо у вас два разных потока будут работать до и после интерактива. Иными словами, совсем без доработок перейти в асинхрон не получится и странно требовать этого от 1С. Но "облегчить жизнь" добавлением какого-нибудь сахара, 1С, наверное могла бы. И я уверен, это наверняка обсуждалось, но потом были применены методики оценки приоритетов, указанные в статье, и данная задача была отброшена.
          0
          Когда вы уже реализуете нормальную вертикальную прокрутку записей? А то даже в 8.3 всего три положения движка — сверху, посередине, снизу.
            0
            Вас усже услышали, правда своеобразно

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

                  Если вы не смогли объяснить бухгалтеру, что список будет тормозить и вызывать только раздражение и не сделали ему удобное открытие отчета, то это ваша недоработка.
                    0
                    Нет, это ваша недоработка, потому что ползунок не работает на стандартных конфигурациях, что мешает предусмотреть механизм получения в динамический список общего количества и нормально прокручивать?
                    А с бухгалтерами мы как-то сами разбираемся, да и не моя эта задача, я в других сферах сейчас работаю, так что так что делайте внушение кому-нибдуь другому, раз уж в вас проснулся инстикт наставника.
                      0
                      Я как-бы не работаю в 1С, поэтому моей эта недоработка быть никак не может :)
                  –1
                  А вот ползунок отпрыгивающий назад, это не тот, который врёт, а это хороший приём, когда очень много данных и скорее всего пользователь их все не захочет смотреть, потому что выдача их ранжирована, например выдача гугла на какой-то запрос, в итоге навигацию вам оставляют только по тому, что вы уже посмотрели, а иметь каждый раз ползунок, где каждый миллиметр это сотни тысяч элементов, это как-то мало интересно. Ну и видимо остальные тоже стараются как могут, но не всегда понимают, что для 100 элементов такое решение — не нужно.
                +2
                Спасибо за материал! А как вы оркеструете релизы? Есть ли некоторый выделенный человек, владеющий product roadmap? А также, есть ли некий выделенный человек, вроде главного архитектора, который определит, совместим ли набор предложенных фич друг с другом.
                  –1
                  И у нас есть достаточно таких примеров, когда мы не брали готовое пожелание или решение, имеющееся в других технологиях, а придумывали и воплощали свою идею. И это давало очень большой эффект.

                  Насчёт эффекта. я весь в сомении, но велосипеды у вас сплошь и рядом, взять хотя бы Бухгалтерию и эта замечательная идея о ускорении, при разделении регистра на налоговый и бухгалтерский учёт, а этот замечательный РАУЗ, а СКД где по типу кубов, сначала тащится все данные и уже потом режутся, это же тихий ужас по объёмам? Да про то, что вы не релизы ни идеи не проверяете никогда, и выпускаете всё сырым, уже давно легенды слагают, возьмите последний релиз платформы 8.3.7, когда половина справочников открывалась пустыми и надо был крутить вверх что бы что-то увидеть, а в списках адресов вообще ничего нельзя было сделать, ваша идея, что форма не должна теперь скролиться, тоже очень оригинальна и что делать с непоместившимися элементами — не понятно, да и не видно, что что-то не влезло. И так можно ткнуть в любой релиз, и везде у вас косяки, если накатили обновление и не затёрлись данные кривой обработкой (да, бывает и такое — без возможности восстановления, 1с потом напишет мы же отозвали, остальное ваши проблемы). значит релиз — удачен. Про ориентированность на пользователей вы тоже классно поёте, на практике, помню зависала у вас регламентированная отчётность, после разбирательства выяснилось, что join платформа как-то криво обрабатывает и строится такой план, который отрабатывает больше 40 минут, я заменил на временную таблицу, стало пару секунд, а служба поддержки сказала — мы принципиально менять не будем ничего, у нас не энтерпрайз решение, поэтому НИКАКИХ оптимизаций запросов, идите нах.
                    0
                    "Исправлена в выпущенной версии" в Вашем багтрекере = "забили" ?

                    В какой мере мы учитываем количество обращений по конкретному пожеланию? — В общем, учитываем. Но это не главный критерий.
                    — остальное можно было не писать. «Пожелания» это не дурь потребителя, клиента, ЗАКАЗЧИКА и ПОКУПАТЕЛЯ.
                    С таким подходом вы добавляете негатива от потребителя, который начинает смотреть на головную контору 1С, как на зажравшегося монстра.
                      –1
                      То есть по вашему, ткнуть в последнюю версию и попасть в недоработку которую видно невооружённым глазом, это — нормально!? и то что вы печёте заплатки на такую дребедень оправдывает постоянный выпуск сырого продукта?
                      Да вы и есть зажравшийся монстр, уже по минусам видно, как неистово вы минусите.
                      А на практие, не слишком шустрая работа платформы и конфигураций это очевидный факт, и только заржавшаяся контора может при этом вместо того, что бы оптимизировать конфигурации пытаться нажиться на этом, делая заведомо тормозной продукт, приговаривая "больше чем на 20 человек не рассчитано это не энетрепрайз", при этом какая-нибудь ЕРП будет не шибко быстрей, но зато есть возможности для оптимизации, когда-нибудь..
                        0
                        Да вы на свои конфигурации посмотрите, при выгрузке из бухгалтерии плана счетов в зуп, половина перечислений дублировалась, потому что одни и те же наборы перечислений в каждой конфигурации прописаны по своему, даже такие элементарные вещи вы не устраняете годами, пользователям-то пофиг, ручками один раз поправят и живут, а об архитектуре и культуре разработки это говорит многое, можете минусить.
                        Про оптимизации я ещё раз повторю, 1с как виндовс работает всё быстрей и быстрей, но только на всё более быстром железе. А принципиальный подход не делать никаких оптимизаций озвученный официально, это достойно, весьма гибкий подход к клиенту. Да напишите в ответ что я что-то должен, как в прошлый раз, я посмеюсь.
                        muz-muz.net/storage/%D0%BF%D0%B8%D1%81%D1%8C%D0%BC%D0%BE%20%D0%B4%D0%B8%D1%80%D0%B5%D0%BA%D1%82%D0%BE%D1%80%D1%83%201%D1%81
                          0
                          как в прошлый раз, я посмеюсь.
                          muz-muz.net/storage/%D0%BF%D0%B8%D1%81%D1%8C%D0%BC%D0%BE%20%D0%B4%D0%B8%D1%80%D0%B5%D0%BA%D1%82%D0%BE%D1%80%D1%83%201%D1%81

                          Так это был ты!!
                            0
                            Теперь PrMex'у будут эту песенку долго припоминать ;-)
                        0
                        Хочу поделится своими наработками. Недавно сделал
                        Кроссплатформенное использование классов .Net из неуправляемого кода. Или аналог IDispatch на Linux

                        Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux

                        Здесь побольше 1С кода.

                        Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux 2

                        Например практически все программисты 1С используют ComОбъект.

                        По моей методе можно использовать
                        NetОбъект,NetТип
                        JavaОбъект,JavaТип

                        И эти объявления будут реально кроссплатформенны.
                        При это различия с ComОбъект минимальны. Имя класса равноценно комовскому ProgID. При этом нет ограничений на используемые типы.
                        Ты можешь написать свою библиотеку поместить в определенное место и использовать её вместо COM. Без регистрации итд. Расширять возможности 1С станет легче.

                        Например сейчас в конфигураторе куча функций, которые есть в стандартных библиотеках. При этом функционал 1С функций сильно недотягивает до стандартных библиотек.
                        Учитывая кроссплатформенность можно использовать нетовские или явовские библиотеки везде где можно. Упрощая программирование.
                        А что касается работы с HTTP,SMPT, JSON то эти библиотеки были задолго до того как 1С их реализовывала, при этом с ошибками и функционалом сильно недотягивающих до .Net или Java.
                        Стоит ли тратить время на то, что можно взять из стандартных библиотек. А ведь можно легко расширить за счет своих сборок.

                        При этом например нетовская библиотека весит всего 65 мегабайт, которую можно включить в дистрибутив и главное это кроссплатформенное решение. Причем нет сложного передавать в параметрах и объекты 1С которые поддерживают аналогичный интерфейс. Можно пойти по пути подсчета ссылок в 1С, а доступ к объектам 1С только на время вызова метода ВК.

                        Например Использование сборок .NET в 1С 7.x b 8.x. Создание внешних Компонент многие бы использовали на равне с ComОбъект, но главная причина её неприменения в том, что она неинтегрирована в 1С.

                        Даже если вы не хотите интегрировать .Net в 1С, то сделать вариант ВК под .Net и Java думаю стоит. Прежде всего для получения объектов ВК и передачи их в параметрах. Кроме того можно добавить доступ по индексу [], получения итератора.
                        Прошу прощения за сумбурность. Вроде как вещь полезная (реальная альтернатива IDispatch), но…

                          0
                            0
                            Добавил статью 1С,Linux,Excel,Word,OpenXML,Net Core

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

                            Самое читаемое