Comments 66
UFO just landed and posted this here
Простите накипело. Эта статья уже не актуальна? Для меня 1C до сих пор остаётся венцом отечественной экономики говна копроэкономики. Одна активация клиентского ПО чего стоит. А версии под Linux? Ещё много боли. Так можно долго перечислять. Эффективные менеджеры, <много матных слов>!
Спасибо, хоть хабру дали заработать.
Спасибо, хоть хабру дали заработать.
Спасибо за полный позитива пост, коллега!
Вы у каждого явления видите только одну сторону?
Ну и не устану повторять — ненависть лучше, чем равнодушие)
Вы у каждого явления видите только одну сторону?
Ну и не устану повторять — ненависть лучше, чем равнодушие)
Пока я вижу только то, что за 25 лет флагманский продукт не довели до ума. К монополисту знаете ли, сложно быть равнодушным.
С удовольствием почитаю Вашу статью о Вашем продукте, доведённом до ума.
Видимо, пока juffinhalli не сочтет, что все проблемы 1С наконец решены, мы не должны публиковать никаких статей на Хабре.
Публикуйтесь на здоровье! Хабру нужно чем-то оплачивать хостинг. Цель моих сообщений это донести до не знакомых с этой кухней хабровчан, что за красивыми рекламными проспектами кроется корыстное желание посадить Вашу компанию на новую ЕRP иглу и выкатывать за этим ещё большие ценники. Наплевательское отношение компании к своим клиентам прилагается бесплатно. И ничего личного. Видно место проклятое (с)
Нас самом деле, для специалиста, принимающего решения об использовании той или иной ERP, ваши сообщения, загрязненные мемами (видимо, как и ваше сознание), ненавистью, и оскорблениями широкому кругу вовлеченных в экосистему, несут нулевую информационную ценность, и являются мусорными в данном месте в данное время.
Мусорить, конечно, ваше право, но конструктивно было бы доносить информацию, которую вы считаете важной, в публикациях соответствующей тематики.
Мусорить, конечно, ваше право, но конструктивно было бы доносить информацию, которую вы считаете важной, в публикациях соответствующей тематики.
Коллега, критиковать всегда просто. Это самый первый способ.
В условиях рынка — можно перейти на другой программный продукт.
В некоторых случаях — это даже очень полезно.
Например — по поводу ценников. Думаю верно будет тогда озвучивать ценники конкурентов?
Как минимум — это будет некоторый сравнительный анализ и очень полезен для «не знакомых с этой кухней»
Можно и дальше продолжать обсуждать.
В целом — в любом программном продукте, есть «неточности, проблемы». Как показывает практика — чем лучше специалист подготовлен — тем меньше этих проблем возникает. В некоторых западных компаниях (и это очень большой плюс) — просто не допускают сотрудников без соответствующей квалификации в запуску и обслуживанию.
По поводу «25 лет». Опять же — предлагаю посмотреть на каком движке сделаны аналоги, и каким годом датируется этот движок. И если говорить за ERP — конкретно — то ей точно не 25 лет. А гар
В условиях рынка — можно перейти на другой программный продукт.
В некоторых случаях — это даже очень полезно.
Например — по поводу ценников. Думаю верно будет тогда озвучивать ценники конкурентов?
Как минимум — это будет некоторый сравнительный анализ и очень полезен для «не знакомых с этой кухней»
Можно и дальше продолжать обсуждать.
В целом — в любом программном продукте, есть «неточности, проблемы». Как показывает практика — чем лучше специалист подготовлен — тем меньше этих проблем возникает. В некоторых западных компаниях (и это очень большой плюс) — просто не допускают сотрудников без соответствующей квалификации в запуску и обслуживанию.
По поводу «25 лет». Опять же — предлагаю посмотреть на каком движке сделаны аналоги, и каким годом датируется этот движок. И если говорить за ERP — конкретно — то ей точно не 25 лет. А гар
Вот этот внедренный подход к разработке — это +100500 в карму 1С.
Ребята встали на очень правильные рельсы, думаю это ощутила уже вся команда и это уже ощущает часть клиентов. А дальше будет ещё лучше.
Большинство других команд разработчиков в нашей о такой «технологии организации работ» пока могут мечтать.
Будучи человеком сопричастным к внедрению и развитию ИТ-систем, и находясь больше на стороне Бизнеса, болею за их «боль» (решение их проблем), могу сказать это серьезная заявка на то, что продукт 1С лет через 10 начнет вытеснять западные решения/продукты в силу лучшего понимания отечественной специфики и более высокой скорости реализации изменений.
Благодарю за статью! +1 вам в карму.
Ребята встали на очень правильные рельсы, думаю это ощутила уже вся команда и это уже ощущает часть клиентов. А дальше будет ещё лучше.
Большинство других команд разработчиков в нашей о такой «технологии организации работ» пока могут мечтать.
Будучи человеком сопричастным к внедрению и развитию ИТ-систем, и находясь больше на стороне Бизнеса, болею за их «боль» (решение их проблем), могу сказать это серьезная заявка на то, что продукт 1С лет через 10 начнет вытеснять западные решения/продукты в силу лучшего понимания отечественной специфики и более высокой скорости реализации изменений.
Благодарю за статью! +1 вам в карму.
Это ваше мнение и вы конечно имеете на него право. Однако на рационально мыслящего человека ваши нелепые ярлыки вряд ли могут произвести впечатление. Как минимум пока вы не уточните уровень вашего профессионализма в данной конкретной отрасли. А пока вы выступаете в роли той бабки, которая всем у подъезда рассказывает.
Репродуцирование мемов вообще не требует какого-либо "видения".
Простите, а какое отношение ваш пост имеет к этой публикации?
НЛО прилетело и удалило эту запись.
Читал прошлые посты от 1С и прямо радовался — количество неадекватных истерик, столько часто устраиваемых "IT специалистами" по поводу 1С, стремилось в них к нулю. Наконец-то, думаю. Но вот, видать, рано радовался.
Как вы работаете с Хранилищем конфигурации в столь масштабном проекте? Не доставляют ли неудобств эксклюзивные захваты объектов для изменения? Отсутсвие бранчей(веток)? Даже в небольшой команде с этим определенные трудности (а так же, с быстродействием самого хранилища).
Разработку мы ведем в хранилищах разработки, которые стоят на поддержке от основного хранилища. Это и есть наши бранчи. Создание бранчей автоматизировано и происходит с помощью СППР. При этом использует пакетный режим запуска "Конфигуратора", т.е. в принципе мы пользуемся штатными возможностями платформы. В одном бранче редко бывает необходимо нескольким разработчикам захватывать один объект.
В основном хранилище происходят заливки проектов и исправления ошибок, поэтому ситуации когда двум разработчикам нужен один объект опять-таки минимизированы, и тем более очень редко бывает, когда объект нужен надолго. В "горячую пору", когда много проектов нужно залить в основное хранилище — это после снятия моратория, связанного с выпуском версии, когда за период моратория накапливается какое-то количество проектов на заливку — мы решаем организационно, выстраивая очередь заливок. Но это не часто бывает.
С быстродействием примерно та же история — в основном хранилище разработка не ведется, поэтому фатальна скорость работы не основного хранилища, а бранчей. В бранчах же история небольшая, поэтому бранчи достаточно шустро работают.
В основном хранилище происходят заливки проектов и исправления ошибок, поэтому ситуации когда двум разработчикам нужен один объект опять-таки минимизированы, и тем более очень редко бывает, когда объект нужен надолго. В "горячую пору", когда много проектов нужно залить в основное хранилище — это после снятия моратория, связанного с выпуском версии, когда за период моратория накапливается какое-то количество проектов на заливку — мы решаем организационно, выстраивая очередь заливок. Но это не часто бывает.
С быстродействием примерно та же история — в основном хранилище разработка не ведется, поэтому фатальна скорость работы не основного хранилища, а бранчей. В бранчах же история небольшая, поэтому бранчи достаточно шустро работают.
Спасибо, весьма ценная информация. В свое время для воркфлоу — основная часть команды на сопровождении правит баги, а другая подгруппа делает новую "фичу", приходилось вручную поднимать копию основного хранилища, и по окончанию работ, вручную мержить правки в основное хранилище. Хорошо, что теперь есть канонически способ, не требующий от человека выполнений функций VCS :)
А есть ли автоматизация бранчей-хотфиксов?
Где правим и как объединяем изменения?
- выпустили свежую версию, создали N бранчей и ведем разработку, часть слили в ствол.
- обнаружили баг.
Где правим и как объединяем изменения?
Обнаружили баг, через СППР создали бранч для разработки багфикса, влили в ствол, N бранчей разработки обновили через механизм поставки из ствола, вроде должно быть так. Код СППР открыт, по идее, можно сделать любые автоматизации под нужный workflow (и даже на основе СППР написать свой велосипед). Жаль, с 1С давно завязал, было бы интересно развернуть такой процесс.
Все операции автоматизируются по максимуму
Интересен список этих операций.
Интересен список этих операций.
Это описано в ИТС. Информация доступна легальным пользователям ИТС.
Привет.
А расскажите немного больше про код ревью.
С помощью какого инструмента вы его делаете?
А расскажите немного больше про код ревью.
С помощью какого инструмента вы его делаете?
- Формируется отчет о сравнении ветки разработки и основного хранилища. Аудитор просматривает изменения, если нужно посмотреть более внимательно, то открывает в Конфигураторе конфигурацию ветки.
- Также проверки кода делаются автоматически с помощью продукта "Автоматическая проверка конфигураций", куда в поставку заложены формальные проверки целого рядов стандартов разработки.
Т.е. способов, что бы ревьювер мог оставить комментарий к строчке кода нет? именно этого очень хочется
Замечания аудитор записывает в СППР. Сюда загружается отчет о сравнении, который при загрузке парсится, по нему заполняется список измененных тех. проектом объектов. Сам отчет аудитор просматривает тоже из СППР в контексте измененных объектов. "Проглядел список измененных объектов — посмотрел что именно изменилось каждом объекте — записал замечания" — все это не выходя из СППР. Замечания регистрируются в ошибками и попадают в общий контроль сроков исправления ошибок.
А всего в 1С:ERP используется около 600 функциональных опций.
Да и общих модулей не шибко меньше. И это не есть хорошо.
Да и общих модулей не шибко меньше. И это не есть хорошо.
У такого масштабного продукта должна быть мощная методологическая проработка в предметной области. Как она происходит? Есть ли она вообще? А то судя по статье — просто партнеры пишут заявки, кто то их рассматривает и принимает решение делать не делать, а дальше поперла разработка.
Почему спрашиваю — вызывают вопросы некоторые термины, подходы и странности в продукте. Создается впечатление, что если методолог и есть, то он давно сдался и нервно курит, закрывшись в кабинете.
Почему спрашиваю — вызывают вопросы некоторые термины, подходы и странности в продукте. Создается впечатление, что если методолог и есть, то он давно сдался и нервно курит, закрывшись в кабинете.
Непонятно разделение на "методическую проработку" и "разработку". Это неразделимые понятия при работе над таким сложным и многовариативным проектом, как "ERP". В ходе разработки ведется методическая проработка вопросов тим-лидами, ответственными за проекты, руководителем разработки. Если это необходимо, то привлекаются сторонние специалисты: проводятся консультации с представителями клиентов (логистами, фин. директорами, производственниками и т.д..), партнеров, юристами, аудиторами, специалистами по юзабилити, производительности и т.д… Это делается на протяжении всей работы над проектом: при выработке начальной концепции, при доработке концепции, при обсуждении сценариев работы пользователей, оценке интерфейсов и т.д… Будут привлекаться другие специалисты или нет, насколько будут привлекаться, на каких этапах — решается индивидуально при работе над каждым проектом.
Прошу прощения если вопрос не совсем по теме — в Комплексной Автоматизации 2 проводки делаются сразу или в отложенном режиме (Как в ERP?). У меня проект бухгалтера исключительно за это зарубили год назад...
Вопрос действительно не по теме, попробуйте обратиться на линию консультации.
Вот когда сотрудник 1С говорит "попробуйте обратиться на линию консультации" это о многом говорит. Когда они ответят (а ответят они что-нибудь в стиле "вы указали не тот регистрационный номер") я забуду в чем вопрос был. :-(. Может лучше кто-нибудь из 1С напишет про Комплексную автоматизацию сюда?
когда сотрудник 1С говорит «попробуйте обратиться на линию консультации» это о многом говорит.Например, о том, что 1С большая организация, в которой разрабатываются десятки очень разных продуктов, и ни один сотрудник не может знать всего обо всех продуктах.
Когда они ответят (а ответят они что-нибудь в стиле «вы указали не тот регистрационный номер») я забуду в чем вопрос был.Наверное, потому, что этот вопрос для вас маловажен.
Вообще-то в первом абзаце данной статьи рассказывалось про разработку КА путем вырезания ее из ERP. Так что то что вы не знаете — не верю. Это не "десятки очень разных продуктов".
Послали вы меня дружно. Очень характерно для представителей 1С. Тут тоже не поспоришь.
Но "большое спасибо" за уделенное время.
Послали вы меня дружно. Очень характерно для представителей 1С. Тут тоже не поспоришь.
Но "большое спасибо" за уделенное время.
в первом абзаце данной статьи рассказывалось про разработку КА путем вырезания ее из ERP. Так что то что вы не знаете — не верю. Это не «десятки очень разных продуктов».
Конечно, не все продукты 1С делаются независимо друг от друга. Из 1С:ERP 2 делаются Комплексная автоматизация, Управление торговлей и Управление торговлей (базовая версия). 1С: Бухгалтерия предприятия выпускается в виде базовой, ПРОФ, КОРП версий, приложения "Предприниматель 2015", и все они адаптируются для разных рынков сбыта. И так далее.
Но даже с учетом этого продуктов у 1С много десятков, посмотрите сами.
https://releases.1c.ru/total?hideUnavailablePrograms=false
Насколько я помню, это настраивается. Для каждой организации можно сделать свою настройку.
Петр, спасибо за статью, всегда читаю с удовольствием, некоторые моменты интересны (и просто «подсмотреть», и опыт перенять)… Но всегда когда доходит до комментариев (в которых часто бывают не менее интересные вещи и мысли, чем в статье, поэтому читаю обязательно) почти всегда вижу одно и то же. Кажется, тут балом правят мнения, что стакан наполовину пуст (а то и вообще пуст), а особенно забавляет (и удручает одновременно) слышать мнения от людей, которые давно не в теме, где-то что-то слышали или может и сталкивались, но давно и не долго и как оно сейчас — понятия не имеют (не всегда конечно так, но очень часто). И удручает то собственно потому, что наверняка есть люди, которым такое мнение будет просто навязано («много плюсиков у комментария» -> «автор прав»), и дальше все по кругу… Это весьма печально для уважаемого все-таки технического ресурса. И в связи с этим всем вопрос к вам — а зачем вам этот блог?)
Спасибо за интерес! Попробую ответить — зачем мне этот блог.
Почти всю свою программерскую жизнь я занимался написанием платформ для ERP — iScala, Epicor, потом Microsoft Dymanix (тут правда писал больше прикладной код). В самом начале 2000-х, мы с коллегами в шведской компании Scala придумали новый фреймворк/платформу ERP, основанную на метаданных и облегчающую жизнь прикладного разработчика. Чуть позже вышли ранние версии Microsoft Business Framework и наш собственный проект заморозили, считая, что Microsoft Business Framework решит все наши задачи. Но MBF так и "не взлетел", а время для реализации своего фреймворка мы упустили.
Когда я в очередной раз оказался на профессиональном распутье (поработав разработчиком, тим-лидом, директором R&D и т.д.), фирма 1С сделала мне очень интересное предложение — заняться продвижением их платформы. Про 1С я всегда был высокого мнения (т.к. были знакомые, писавшие платформу 1С), но, познакомившись поближе с нынешней платформой, я понял, что примерно вот это мы с коллегами и хотели написать лет 15 назад. Но в силу ряда причин (в том числе и отсутствия ряда экспертиз в прикладных областях) не смогли.
А в сравнении с конкурентами (которых я немало повидал, а часть из них даже написал) платформа 1С обладает огромным числом преимуществ; главные из них (на мой взгляд) — продуманная объектная модель (не нагромождение классов и таблиц, а реальные объекты из мира учетных систем с минимумом программного кода), продуманная система обновления, кросс-платформенность (в особенности наличие веб-клиента "бесплатно", без единой строчки доп. кода, и мобильный фреймворк). Понятно, что у каждой системы есть баги, недостатки. Но концепт, зерно, заложенное в основу платформы 1С — самое, на мой взгляд, правильное, по сравнению с другими продуктами, представленными на рынке.
"А мужики-то не знают!". Вот я и пытаюсь донести это до ИТ-сообщества. Парадокс ситуации в том, что чтобы понять всю прелесть платформы 1С — надо написать на C++/Java/Delphi парочку учетных систем с нуля. Понаступать на грабли, поизобретать велосипеды. А потом написать учетную систему на платформе 1С. И оценить трудозатраты.
А у нас многие разработчики 1С кроме 1С ничего не щупали. Отсюда их избалованность и пресыщенность. А ведь полезно иногда посмотреть, как выглядят проблемы пользователей/разработчиков конкурирующих систем.
Хабр же считаю самым лучшим на сегодня IT-ресурсом. Не без недостатков, конечно.
Уф, много написал, но, надеюсь, мысль — зачем мне нужен этот блог — донес.
Почти всю свою программерскую жизнь я занимался написанием платформ для ERP — iScala, Epicor, потом Microsoft Dymanix (тут правда писал больше прикладной код). В самом начале 2000-х, мы с коллегами в шведской компании Scala придумали новый фреймворк/платформу ERP, основанную на метаданных и облегчающую жизнь прикладного разработчика. Чуть позже вышли ранние версии Microsoft Business Framework и наш собственный проект заморозили, считая, что Microsoft Business Framework решит все наши задачи. Но MBF так и "не взлетел", а время для реализации своего фреймворка мы упустили.
Когда я в очередной раз оказался на профессиональном распутье (поработав разработчиком, тим-лидом, директором R&D и т.д.), фирма 1С сделала мне очень интересное предложение — заняться продвижением их платформы. Про 1С я всегда был высокого мнения (т.к. были знакомые, писавшие платформу 1С), но, познакомившись поближе с нынешней платформой, я понял, что примерно вот это мы с коллегами и хотели написать лет 15 назад. Но в силу ряда причин (в том числе и отсутствия ряда экспертиз в прикладных областях) не смогли.
А в сравнении с конкурентами (которых я немало повидал, а часть из них даже написал) платформа 1С обладает огромным числом преимуществ; главные из них (на мой взгляд) — продуманная объектная модель (не нагромождение классов и таблиц, а реальные объекты из мира учетных систем с минимумом программного кода), продуманная система обновления, кросс-платформенность (в особенности наличие веб-клиента "бесплатно", без единой строчки доп. кода, и мобильный фреймворк). Понятно, что у каждой системы есть баги, недостатки. Но концепт, зерно, заложенное в основу платформы 1С — самое, на мой взгляд, правильное, по сравнению с другими продуктами, представленными на рынке.
"А мужики-то не знают!". Вот я и пытаюсь донести это до ИТ-сообщества. Парадокс ситуации в том, что чтобы понять всю прелесть платформы 1С — надо написать на C++/Java/Delphi парочку учетных систем с нуля. Понаступать на грабли, поизобретать велосипеды. А потом написать учетную систему на платформе 1С. И оценить трудозатраты.
А у нас многие разработчики 1С кроме 1С ничего не щупали. Отсюда их избалованность и пресыщенность. А ведь полезно иногда посмотреть, как выглядят проблемы пользователей/разработчиков конкурирующих систем.
Хабр же считаю самым лучшим на сегодня IT-ресурсом. Не без недостатков, конечно.
Уф, много написал, но, надеюсь, мысль — зачем мне нужен этот блог — донес.
На аватарке вы? Если да, когда и на каком аэродроме снято? :)
Я, аэродром Коробчеево АКА Аэроград, 28 августа 2015 г.
Фотосессия "1С в облаках" в поддержку продукта 1cFresh.
Фотосессия "1С в облаках" в поддержку продукта 1cFresh.
Функциональная модель проекта в нотации IDEF0 разрабатывается и хранится в СППР.
1. Кем она разрабатывается? Неужели вы ее разрабатываете в редакторе графических схем внутри СППР? Это ведь абсалютно неудобное средство, например по сравнению с BPWin. Как вы переносите элементы с уровня на уровень?
2. Вы написали, что в СППР вносятся изменения на этапе 3, при этом на этапе 5 проект может быть не готов в включению в очередной релиз. То есть изменения вносятся в какую-то ветку СППР, а затем каким то образом переносятся в основную ветку?
3. Кто пишет справку, сами разработчики или отдельные технические писатели. Как синхронизирована встроенная справка и документация?
4. Как разработчики ERP смирились с тем, что запись конфигурации после небольшого изменения занимает от 40 секунд (при работе на сервере приложений) до 3 минут при файловой базе?
5. Почему в состав конфигурации входит регламентированная отчетность, которая занимает огромную часть из указанного вами объема строк кода и которая может поставляться отдельной поставкой и также отдельно обновляться?
6. В СППР есть поле оценка. Кто ее выполняет и контролирует. Есть ли анализ, почему оценка была превышена, есть ли какие-то штрафы для разработчика, регулярно превышающего оценку?
7. По вашей оценке, если необходимо добавить в конфигурацию в какой либо справочник новый реквизит и вывести его на форму сколько человеко-часов это потребует (хотя бы приблизительно общее количество времени на обсуждение, прототип, разработка, тестирование, справка, внесение в СППР и т.п.)
1. Кем она разрабатывается? Неужели вы ее разрабатываете в редакторе графических схем внутри СППР? Это ведь абсолютно неудобное средство, например по сравнению с BPWin. Как вы переносите элементы с уровня на уровень?
Разрабатывается отвественными за проекты и/или тим-лидами. Правим внутри СППР. Средство для редактирования схем действительно не самое удобно, но нам для схемы самое важное — это даже не графическое представление, а связи с объектами данных, которые мы храним в соотвествующем справочнике СППР. Можно, конечно, подумать об интеграции, скажем, BPWin и СППР, чтобы схемы править с помощью графического редактора BPWin и потом каким-то образом связывать элементы схемы со справочниками СППР, но не факт что эта связка будет хорошо работать, к тому же тогда СППР перестанет быть самодостаточным продуктом. Сейчас мы рисуем схемы в СППР, СППР же делает формальные проверки этих схем (ну, например, что связи родительской схемы и дочерней не противоречивы).
Вопрос по перенос элементов с уровня на уровень не понятен. В СППР есть средства для создания дочерних схем на основе родительских — см. контекстное меню в редактора схем в СППР.
2. Вы написали, что в СППР вносятся изменения на этапе 3, при этом на этапе 5 проект может быть не готов в включению в очередной релиз. То есть изменения вносятся в какую-то ветку СППР, а затем каким то образом переносятся в основную ветку?
В СППР нет веток. Информация, отраженная там соотвествует не выпущенной версии, а разрабатываемой. Справку мы пишем в СППР уже после заливки проекта в основное хранилище, поэтому по справке не опережения выпуска, а схемы актуализируем до заливки, поэтому выпущенные схемы могут опережать выпущенный функционал.
3. Кто пишет справку, сами разработчики или отдельные технические писатели. Как синхронизирована встроенная справка и документация?
Справку пишут разработчики в СППР в рамках этапа заливки в основное хранилище, технические писатели ее проверяют в СППР (являются согласующими всех технических проектов). Заливка справки из СППР в хранилище делается централизировано в процессе сборки релиза. Документацию пишут технические писатели.
4. Как разработчики ERP смирились с тем, что запись конфигурации после небольшого изменения занимает от 40 секунд (при работе на сервере приложений) до 3 минут при файловой базе?
«Привычка свыше нам дана...» Только у нас наблюдения другие — с файловой базой, размещенной локально, конфигуратор при разработке работает быстрее, чем с клиент-серверной. А цифры примерно те же.
5. Почему в состав конфигурации входит регламентированная отчетность, которая занимает огромную часть из указанного вами объема строк кода и которая может поставляться отдельной поставкой и также отдельно обновляться?
Обновления поставляются в виде одного файла. В него входит и регл. отчетность, и, например, драйверы оборудования. Раньше все поставлялось отдельно. Это единое решение для всех конфигураций нового поколения. Так проще с организационной точки зрения, а также уменьшает количество ошибок при обновлении: ну, скажем, раньше приходилось разбираться с ошибками, что комплект отчетности подключили к версии конфигурации, которая не может с ним работать. Вообще современная тенденция — программы обновляются автоматически, ничего у пользователя не спрашивая, поэтому вообще пользователю не принципиально, какими файлами это обновление приходит. Конечно, мы понимаем, для систем уровня ERP автоматическое обновление (по крайней мере пока) скорее утопия, чем реальность. Но стремиться к этому нужно.
Так же, при изменении отчетности достаточно часто меняется не только сама отчетность, но и учетные механизмы. Например, поменяли форму журнала учета счетов фактур. Но при этом ФНС поменяла не только форму, но и иструкцию по заполнению, поэтому пришлось дописывать не только «заполнялку» регл. формы, но и учетные механизмы.
6. В СППР есть поле оценка. Кто ее выполняет и контролирует. Есть ли анализ, почему оценка была превышена, есть ли какие-то штрафы для разработчика, регулярно превышающего оценку?
Не очень понятно, о какой оценке идет речь. В СППР есть задачи, в задачах есть трудоемкость. Трудоемкость согласует рукововодитель разработки. В конце месяца делается план-фактный анализ — сколько сотрудник трудоемкости согласовал и сколько реально потратил. Информация о том, сколько реально потратил берется из ежедневных отчетов, которые мы ведем в внутренней базе «1С: Документооборот» (кстати с 1С: Документооборот интегрирована не только ERP, но и СППР — можно не выходя из СППР делать замеры фактически потраченного времени на задачу, эта информация будет хранится в 1С: Документооборот).
7. По вашей оценке, если необходимо добавить в конфигурацию в какой либо справочник новый реквизит и вывести его на форму сколько человеко-часов это потребует (хотя бы приблизительно общее количество времени на обсуждение, прототип, разработка, тестирование, справка, внесение в СППР и т.п.) "
Нет такой задачи «добавить справочник». Мы задачу формулируем так: «реализовать в программе такой-то сценарий работы». Обсуждаем мы именно эту задачу, делаем для нее прототипы. Для реализации согласованного, может потребоваться добавить справочник, и это займет сколько-то времени — но это будет просто время на разработку.
По оценке — Вы же сами понимаете, что нельзя дать оценку абстрактному «добавить справочник». Если добавить справочник «Номенклатура» со всем ее обвесом — несколько человеко-лет. Если справочник — ДрагоценныеМатериалы — часа четыре (с учетом заполнения его из макета).
1. Я имел ввиду перенос блока с уровня на уровень, например необходимо добавить новый блок на уровень, а их там уже 5 и нужно вставить еще один уровень, на котором будет 3 элемента, а существующие необходимо между ними распределить. Не нашел в СППР функционала, который позволяет это сделать без повторного ввода.
5. Никто не мешает делать в конфигурации дублирующиеся учетные механизмы, под старую и под новую версию отчетности, но то что отчетность занимает почти треть от всей конфигурации — это слишком.
6. То есть исполнитель ставит оценку, а руководитель разработки ее подтверждает? Есть ли санкции для разработчика, который постоянно не укладывается в оценку? Или его просто переводят на обновление регламентированной отчетности?
5. Никто не мешает делать в конфигурации дублирующиеся учетные механизмы, под старую и под новую версию отчетности, но то что отчетность занимает почти треть от всей конфигурации — это слишком.
6. То есть исполнитель ставит оценку, а руководитель разработки ее подтверждает? Есть ли санкции для разработчика, который постоянно не укладывается в оценку? Или его просто переводят на обновление регламентированной отчетности?
Пример разработки ERP:
ШаблонСообщения = НСтр(«ru = 'Номенклатура %НоменклатураХарактеристика% %Назначение%
|Превышен оперативный складской остаток на складе „“%Склад%»" на %Количество% %Единица%'");
Если строку внутри НСтр передать переводчику для перевода на английский язык, что он напишет? И так во всей конфигурации!
ШаблонСообщения = НСтр(«ru = 'Номенклатура %НоменклатураХарактеристика% %Назначение%
|Превышен оперативный складской остаток на складе „“%Склад%»" на %Количество% %Единица%'");
Если строку внутри НСтр передать переводчику для перевода на английский язык, что он напишет? И так во всей конфигурации!
А в чем проблема перевести строковый шаблон? Ну да, это не gettext и .po-файлами, выглядит слегка непривычно.
То, что в переводе должны остаться русские параметры замены. То есть будет что-то типа Item %НоменклатураХарактеристика% %Назначение%…
Это да, хотя непонятно, кому нужна английская локализация оригинальной ERP. А вот в БСП, насколько я смотрел, стараются в коде использовать английскую нотацию.
Потому, что БСП пишет опытная команда разработчиков, которая понимает для чего функция НСтр и поэтому использует индексы параметра в строках НСтр, а разработчики ERP по всей видимости новички.
Я не думаю, что над таким серьезным продуктом могут работать «новички».
Из-за неоднозначного косяка с НСтр делать вывод о профессионализме команды…
Господи, как я люблю комментарии в интернете.
Из-за неоднозначного косяка с НСтр делать вывод о профессионализме команды…
Господи, как я люблю комментарии в интернете.
А какой я еще должен сделать вывод? Если данный формат строк для перевода используется во всей конфигурации, значит это прописано в регламенте разработки. Почему за все это время никто не обратил на это внимание?
Переводчик с русского на английский должен русский знать, поэтому не понятная сама постановка вопроса. Разобраться же с тем, что значит и для чего используется каждый параметр проще, если у параметров осмысленные названия, а не цифры. В приведенном примере, заменим все на цифры
(«ru = 'Номенклатура %1 %2 Превышен оперативный складской остаток на складе “%3 на %4 %5");
Вот смотрит переводчик на эту строку. Что может означает параметр 2? Нужно ли между параметром 1 и 2 вставлять какие-то предлоги, артикли и т.п… И вообще последовательность параметров в сообщении может зависеть от языка. То, что на русском корректно сначала назвать чего не хватает, а потом сказать где не хватает, не означает, что в другом языке это будет корректно, где-то более естественным будет определенный порядок. Значит переводчику может понадобиться параметры в сообщении перечислить в другом порядке. И ему, переводчику, будет легче оперировать осмысленными названиями.
Так же и разработчикам. Ошибку, что ты в сообщении неправильно сделал замену, и написал
%НоменклатураХарактеристика% заменить на Выборка.Склад
намного проще, чем проверить, что ты номенклатуру и склад при замене не перепутал местами.
Но это все, если мы говорим о переводе на другой язык только пользовательского интерфейса. Если же мы говорим о переводе на английский кода конфигурации, то тем боле вопрос не понятен — переводить нужно все, все имена переменных. В т.ч. переменную %НоменклатураХарактеристика%. Если будет решен вопрос, как переводить другие имена других переменных, то так же нужно будет поступать и с этими.
(«ru = 'Номенклатура %1 %2 Превышен оперативный складской остаток на складе “%3 на %4 %5");
Вот смотрит переводчик на эту строку. Что может означает параметр 2? Нужно ли между параметром 1 и 2 вставлять какие-то предлоги, артикли и т.п… И вообще последовательность параметров в сообщении может зависеть от языка. То, что на русском корректно сначала назвать чего не хватает, а потом сказать где не хватает, не означает, что в другом языке это будет корректно, где-то более естественным будет определенный порядок. Значит переводчику может понадобиться параметры в сообщении перечислить в другом порядке. И ему, переводчику, будет легче оперировать осмысленными названиями.
Так же и разработчикам. Ошибку, что ты в сообщении неправильно сделал замену, и написал
%НоменклатураХарактеристика% заменить на Выборка.Склад
намного проще, чем проверить, что ты номенклатуру и склад при замене не перепутал местами.
Но это все, если мы говорим о переводе на другой язык только пользовательского интерфейса. Если же мы говорим о переводе на английский кода конфигурации, то тем боле вопрос не понятен — переводить нужно все, все имена переменных. В т.ч. переменную %НоменклатураХарактеристика%. Если будет решен вопрос, как переводить другие имена других переменных, то так же нужно будет поступать и с этими.
1. Перед параметрами необходимо писать описания. Рядом стоящие параметры разрывать нельзя. У меня было несколько проектов по переводу и никогда переводчик не жаловался на недостаток информации в сообщениях. Главное, чтобы переводчик должен знать предметную область. На одном проекте кстати один разработчик стал делать как вы в ERP, переводчик это дело сразу зарезал, т.к. системы технического перевода типа SDL Trados Studio очень плохо работают с двуязычными строками
2. Технические ошибки всегда были, а ошибки перевода вообще никак на функциональность не влияют
3. Про перевод текста конфигурации вопрос гораздо более сложный и думаю вы с ним столкнетесь, когда захотите продавать ERP за пределами русскоязычной зоны.
2. Технические ошибки всегда были, а ошибки перевода вообще никак на функциональность не влияют
3. Про перевод текста конфигурации вопрос гораздо более сложный и думаю вы с ним столкнетесь, когда захотите продавать ERP за пределами русскоязычной зоны.
UFO just landed and posted this here
Sign up to leave a comment.
Как разрабатывается 1С:ERP (и не только)