Внимание! Тема закрыта. Добавлять сообщения в закрытую тему запрещено.
В данной теме можно и нужно обращаться за подробностями по вышеуказанной секции. По докладчикам, по темам и т.д.
А также готовить свои вопросы к круглому столу/столам.
Идет наполнение подробной информации о докладчикам - по мере редактирования, новости будут публиковаться здесь же.
Сайт конференции:
Тезисы у нас следующие:
Секция посвящена практикам владения платформы 1С:Предприятие в рамках информационного поля компании.
Будут продемонстрированы и обсуждены следующие кейсы
• Как создавать конфигурации, которые живут долго
• Борьба с энтропией конфигураций
• Управление моделями данных для отражения реальности
• Управление жизненным циклом конфигураций в рамках общей коллекции программных продуктов
• Способы достижения гибкости разрабатываемых систем при быстро меняющихся внешних факторах
• Способы создания многокомпонентных конфигураций 1С
• Алгоритмы разрешения проблем и противоречий, возникающих в рамках жизненного цикла конфигураций
Будут рассмотрены примеры как на типовых конфигурациях 1С, так и на отраслевых и созданных «с нуля».
Все приглашенные эксперты будут участвовать в круглых столах, для ответа на конкретные вопросы по освещаемых темам.
---
Если отвлечься, то основное что команда докладчиков хочет вам рассказать, что пока остальные играют в проектные технологии - нам с вами необходимо "владеть" платформой 1С, в режиме когда не всё и не всегда можно реализовать на 1С. А также в ситуации, когда вокруг 1С есть много интересных методик и подходов.
А также готовить свои вопросы к круглому столу/столам.
Идет наполнение подробной информации о докладчикам - по мере редактирования, новости будут публиковаться здесь же.
Сайт конференции:
Тезисы у нас следующие:
Секция посвящена практикам владения платформы 1С:Предприятие в рамках информационного поля компании.
Будут продемонстрированы и обсуждены следующие кейсы
• Как создавать конфигурации, которые живут долго
• Борьба с энтропией конфигураций
• Управление моделями данных для отражения реальности
• Управление жизненным циклом конфигураций в рамках общей коллекции программных продуктов
• Способы достижения гибкости разрабатываемых систем при быстро меняющихся внешних факторах
• Способы создания многокомпонентных конфигураций 1С
• Алгоритмы разрешения проблем и противоречий, возникающих в рамках жизненного цикла конфигураций
Будут рассмотрены примеры как на типовых конфигурациях 1С, так и на отраслевых и созданных «с нуля».
Все приглашенные эксперты будут участвовать в круглых столах, для ответа на конкретные вопросы по освещаемых темам.
---
Если отвлечься, то основное что команда докладчиков хочет вам рассказать, что пока остальные играют в проектные технологии - нам с вами необходимо "владеть" платформой 1С, в режиме когда не всё и не всегда можно реализовать на 1С. А также в ситуации, когда вокруг 1С есть много интересных методик и подходов.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
У меня такие вопросы и темы, которые хотелось бы, что бы затронули:
1. Когда не стоит все выбрасывать и переписывать по новому, а просто доработать необходимый функционал.
2. Многокомпонентные системы: поддержка отдельных компонентов их обновление, варианты уменьшения связности , БСП - эталон?
3. Кто-либо считает процент покрытия кода тестами, насколько ожидаемое поведение покрытое тестами соответствует действительности.
1. Когда не стоит все выбрасывать и переписывать по новому, а просто доработать необходимый функционал.
2. Многокомпонентные системы: поддержка отдельных компонентов их обновление, варианты уменьшения связности , БСП - эталон?
3. Кто-либо считает процент покрытия кода тестами, насколько ожидаемое поведение покрытое тестами соответствует действительности.
(2) pumbaE,
1. Это тема моего доклада, как не странно. Поэтому я обязательно учту.
2. На эту обязательно расскажет Андрей Лесков - собственно это его красная линия доклада
3. А эту тему освещают Артур Аюханов и Павлюк Евгений - в реальности там веселей подход чем просто теоритическиое покрытие тестами.
(4) Сложность в том, что мы уже думали над этим и выступали с этим предложением, но пока не совсем ясно с кем действительно поменяться. У Ирины Павленко некоторые докладчики могут появится только в четверг в силу сильной загруженности (производственная специфика). Поэтому вопрос - а почему вы предлагаете перенос ? у вас есть пересечение по другой интересной секции ? Дело в том, что основная наша красная линия "Когда уходят внедренцы и маркетинг софтверных компаний, как жить в мире с 1С:Предприятием". Поэтому наша целевая аудитория не должна пересекаться с проектами внедрения Кунташова и мобильной платформой Шерстобитова.
И еще shootnik - можем вам предложить следующее: я обычно практикую следующий формат - вы можете заполнить небольшой опросник по необходммому вам к рассмотрению кейсу и мы обязательно разберем вашу проблему и процесс ее разбора вы увидите по видео-трансляции
1. Это тема моего доклада, как не странно. Поэтому я обязательно учту.
2. На эту обязательно расскажет Андрей Лесков - собственно это его красная линия доклада
3. А эту тему освещают Артур Аюханов и Павлюк Евгений - в реальности там веселей подход чем просто теоритическиое покрытие тестами.
(4) Сложность в том, что мы уже думали над этим и выступали с этим предложением, но пока не совсем ясно с кем действительно поменяться. У Ирины Павленко некоторые докладчики могут появится только в четверг в силу сильной загруженности (производственная специфика). Поэтому вопрос - а почему вы предлагаете перенос ? у вас есть пересечение по другой интересной секции ? Дело в том, что основная наша красная линия "Когда уходят внедренцы и маркетинг софтверных компаний, как жить в мире с 1С:Предприятием". Поэтому наша целевая аудитория не должна пересекаться с проектами внедрения Кунташова и мобильной платформой Шерстобитова.
И еще shootnik - можем вам предложить следующее: я обычно практикую следующий формат - вы можете заполнить небольшой опросник по необходммому вам к рассмотрению кейсу и мы обязательно разберем вашу проблему и процесс ее разбора вы увидите по видео-трансляции
Хотелось бы немного опыта по поводу того, как определить какая отрасль востребована или будет востребована, а какую отрасль лучше уже забыть. Все это нужно для пониманмия как наиболее эффективно тратить средства на обучение или переобучение сотрудников, определение целевой группы потенциальных клиентов, создания их отраслевых решений или инструментов. Как получив опыт от 1-3 заказчиков одной отрасли, этот опыт не умирал вместе с окончанием проектов.
(9) maxx, Несколько раз перечитал ваше сообщение. Несколько раз порывался написать ответ. В итоге понял, что думается мне, я не совсем пойму, что бы вы хотели услышать от докладчиков.
Давайте я пофантазирую, а вы меня поправите.
Вы компания разработчик и хотите (уже разрабатываете) отраслевые решения.
Вы разрабатываете отраслевое решение под конкретный проект/проекты и думаете каким образом повторно использовать комплект изменений которые создали в рамках проекта внедрения.
Вообще - это скорее тема Александра Кунташова. Но я попробую ответить.
Отраслевой опыт - каждый очень специфичен: сельское хозяйство, торговля, промышленность, лизинг или еще что-то.
Для внедренческой компании важно иметь методологов данной отрасли, однако вы должны понять что методологи сосредоточен в той или иной мере на стороне заказчика, нежели чем на вашей. Поэтому с вашей стороны, должны присутствовать только аналитики и разработчики. Если вы хотите создать у себя экспертизу консалтинга в придачу - здесь действительно никаких инвестиций не хватит, так как это отдельная от программных продуктов отрасль.
Теперь, если бы я отвечал блиц-опросом на ваши вопросы, я бы ответил так, хотя думаю что Александр Кунташов ответит более полно вместе со своей командой докладчиков, так вот:
1. какая отрасль востребована, какая не востребована ? Востребованы все, важнее всего вопрос - какая отрасль еще в зачаточном состоянии по автоматизации
2. как эффективно тратить деньги на обучении:
а. разработчиков - обучении инженерии программного обеспечение
б. аналитиков - обучение системному мышление, методикам анализа, методикам проектирования сценариев использования
в. консалтеров - стрессоустойчивости
3. как получив опыт, он бы не умирал - опыт должен фиксироваться в виде сценариев использования потенциального программного продукта: сценарии отдельно, продукт отдельно = таким образом можно менять платформы и код, оставляя ожидаемое поведение по сценариям.
Давайте я пофантазирую, а вы меня поправите.
Вы компания разработчик и хотите (уже разрабатываете) отраслевые решения.
Вы разрабатываете отраслевое решение под конкретный проект/проекты и думаете каким образом повторно использовать комплект изменений которые создали в рамках проекта внедрения.
Вообще - это скорее тема Александра Кунташова. Но я попробую ответить.
Отраслевой опыт - каждый очень специфичен: сельское хозяйство, торговля, промышленность, лизинг или еще что-то.
Для внедренческой компании важно иметь методологов данной отрасли, однако вы должны понять что методологи сосредоточен в той или иной мере на стороне заказчика, нежели чем на вашей. Поэтому с вашей стороны, должны присутствовать только аналитики и разработчики. Если вы хотите создать у себя экспертизу консалтинга в придачу - здесь действительно никаких инвестиций не хватит, так как это отдельная от программных продуктов отрасль.
Теперь, если бы я отвечал блиц-опросом на ваши вопросы, я бы ответил так, хотя думаю что Александр Кунташов ответит более полно вместе со своей командой докладчиков, так вот:
1. какая отрасль востребована, какая не востребована ? Востребованы все, важнее всего вопрос - какая отрасль еще в зачаточном состоянии по автоматизации
2. как эффективно тратить деньги на обучении:
а. разработчиков - обучении инженерии программного обеспечение
б. аналитиков - обучение системному мышление, методикам анализа, методикам проектирования сценариев использования
в. консалтеров - стрессоустойчивости
3. как получив опыт, он бы не умирал - опыт должен фиксироваться в виде сценариев использования потенциального программного продукта: сценарии отдельно, продукт отдельно = таким образом можно менять платформы и код, оставляя ожидаемое поведение по сценариям.
(11)
>>Вы компания разработчик и хотите (уже разрабатываете) отраслевые решения.
>>Вы разрабатываете отраслевое решение под конкретный проект/проекты и думаете каким образом повторно >>использовать комплект изменений которые создали в рамках проекта внедрения.
Да вы угадали
>>Для внедренческой компании важно иметь методологов данной отрасли, однако вы должны понять что методологи >>сосредоточен в той или иной мере на стороне заказчика, нежели чем на вашей. Поэтому с вашей стороны, должны >>присутствовать только аналитики и разработчики.
Тут такой момент, что если заранее подготовится к работе в отрасли, то клиент скорее всего закажет у тебя проект, нежели у конкурентов. Чтобы клиент понимал, что на тебе не будут учится, а будут по-настоящему внедрять. Поэтому вопрос основной: стоит ли играть на опережение в плане подготовки знаниям конкретной области или же появится заказ клиента тогда и будем разбираться?
>>3. как получив опыт, он бы не умирал - опыт должен фиксироваться в виде сценариев использования >>потенциального программного продукта: сценарии отдельно, продукт отдельно = таким образом можно менять >>платформы и код, оставляя ожидаемое поведение по сценариям.
Вопрос наверно состоит в следующем: если активно работали года 2-3 по одной отрасли, потом перерыв в года 3, потом появляются потенциальные заказы. За перерыв в работе, программу нужно менять (смена платформы, технологий), старых сотрудников уже тех нет, нужно обучать новых, что-то за годы появилось в этой отрасли , что мы уже не знаем и всё надо изучать. Как в этом случае лучше всего "законсервировать" или поддерживать опыт, наработки.
>>Вы компания разработчик и хотите (уже разрабатываете) отраслевые решения.
>>Вы разрабатываете отраслевое решение под конкретный проект/проекты и думаете каким образом повторно >>использовать комплект изменений которые создали в рамках проекта внедрения.
Да вы угадали
>>Для внедренческой компании важно иметь методологов данной отрасли, однако вы должны понять что методологи >>сосредоточен в той или иной мере на стороне заказчика, нежели чем на вашей. Поэтому с вашей стороны, должны >>присутствовать только аналитики и разработчики.
Тут такой момент, что если заранее подготовится к работе в отрасли, то клиент скорее всего закажет у тебя проект, нежели у конкурентов. Чтобы клиент понимал, что на тебе не будут учится, а будут по-настоящему внедрять. Поэтому вопрос основной: стоит ли играть на опережение в плане подготовки знаниям конкретной области или же появится заказ клиента тогда и будем разбираться?
>>3. как получив опыт, он бы не умирал - опыт должен фиксироваться в виде сценариев использования >>потенциального программного продукта: сценарии отдельно, продукт отдельно = таким образом можно менять >>платформы и код, оставляя ожидаемое поведение по сценариям.
Вопрос наверно состоит в следующем: если активно работали года 2-3 по одной отрасли, потом перерыв в года 3, потом появляются потенциальные заказы. За перерыв в работе, программу нужно менять (смена платформы, технологий), старых сотрудников уже тех нет, нужно обучать новых, что-то за годы появилось в этой отрасли , что мы уже не знаем и всё надо изучать. Как в этом случае лучше всего "законсервировать" или поддерживать опыт, наработки.
(12)
Заранее подготовиться почти невозможно (можно лишь в общих чертах понять проблемы\специфику отрасли) - все тонкости (а их обычно не мало) - обычно узнаешь уже от клиента. Если решили сделать универсальное отраслевое решение - тогда конечно необходимо полностью разобраться в специфики отрасли иначе "...появится заказ клиента тогда и будем разбираться".
По своему опыту могу сказать, что за 2-3 года ничего существенного нового в отраслях (в учете) не появляется (проблемы те же, что были и 10 лет назад)
Тут такой момент, что если заранее подготовится к работе в отрасли, то клиент скорее всего закажет у тебя проект, нежели у конкурентов. Чтобы клиент понимал, что на тебе не будут учится, а будут по-настоящему внедрять. Поэтому вопрос основной: стоит ли играть на опережение в плане подготовки знаниям конкретной области или же появится заказ клиента тогда и будем разбираться?
Заранее подготовиться почти невозможно (можно лишь в общих чертах понять проблемы\специфику отрасли) - все тонкости (а их обычно не мало) - обычно узнаешь уже от клиента. Если решили сделать универсальное отраслевое решение - тогда конечно необходимо полностью разобраться в специфики отрасли иначе "...появится заказ клиента тогда и будем разбираться".
Вопрос наверно состоит в следующем: если активно работали года 2-3 по одной отрасли, потом перерыв в года 3, потом появляются потенциальные заказы. За перерыв в работе, программу нужно менять (смена платформы, технологий), старых сотрудников уже тех нет, нужно обучать новых, что-то за годы появилось в этой отрасли , что мы уже не знаем и всё надо изучать. Как в этом случае лучше всего "законсервировать" или поддерживать опыт, наработки.
По своему опыту могу сказать, что за 2-3 года ничего существенного нового в отраслях (в учете) не появляется (проблемы те же, что были и 10 лет назад)
(12) maxx, Если я вас понимаю, Вы просто не хотите инвестировать в проект, возврат инвестиций по которому пойдет только через 3 года.
Тогда все очень просто - начинайте готовить компонент к системе, небольшой. В вашем случае просто необходимо делать не отраслевые решения, а отраслевые компоненты. Что вы выберете в качестве компонента - это уже ваш выбор . Только боже вас упаси думать по простому что "компонент" = "подсистема". Компонентом может быть все что угодно - например 8.3 эргономичная форма для УПП: там важно только продумать формат поставки, формат встраивания и формат следования версиям УПП.
Надеюсь идея понятна ? Я думаю вам действительно нужен Кунташов. Я думаю он коснется процесса оценки возврата инвестиций, я же буду на своем докладе говорить о методиках разрешения противоречий наподобии вашего.
А тему именно отраслевых решений будут рассматривать больше в секции Ирины Павленко и частично в других.
Со своей стороны могу вам сказать как заказчик - моя оценка, что большинство текущих отраслевых решений сильно проигрывают не по методике бизнес-процессов, а по внутреннему качеству реализации. Есть отдельные единицы на рынке, но их меньшинство. Поэтому на своей работе мне легче реализовать свое отраслевое решение силами in-house разработчиков, чем использовать отраслевое.
Тогда все очень просто - начинайте готовить компонент к системе, небольшой. В вашем случае просто необходимо делать не отраслевые решения, а отраслевые компоненты. Что вы выберете в качестве компонента - это уже ваш выбор . Только боже вас упаси думать по простому что "компонент" = "подсистема". Компонентом может быть все что угодно - например 8.3 эргономичная форма для УПП: там важно только продумать формат поставки, формат встраивания и формат следования версиям УПП.
Надеюсь идея понятна ? Я думаю вам действительно нужен Кунташов. Я думаю он коснется процесса оценки возврата инвестиций, я же буду на своем докладе говорить о методиках разрешения противоречий наподобии вашего.
А тему именно отраслевых решений будут рассматривать больше в секции Ирины Павленко и частично в других.
Со своей стороны могу вам сказать как заказчик - моя оценка, что большинство текущих отраслевых решений сильно проигрывают не по методике бизнес-процессов, а по внутреннему качеству реализации. Есть отдельные единицы на рынке, но их меньшинство. Поэтому на своей работе мне легче реализовать свое отраслевое решение силами in-house разработчиков, чем использовать отраслевое.
(14)
Спасибо за направление, будут смотреть в онлайне.
>>Со своей стороны могу вам сказать как заказчик - моя оценка, что большинство текущих отраслевых решений сильно >>проигрывают не по методике бизнес-процессов, а по внутреннему качеству реализации. Есть отдельные единицы на >>рынке, но их меньшинство. Поэтому на своей работе мне легче реализовать свое отраслевое решение силами in->>house разработчиков, чем использовать отраслевое.
Если у вас большое предприятие и имеет в штате своих разработчиков, вы скорее всего никогда не купите отраслевое, ведь своё можно сделать как вам нужно без лишнего обвешивания функционала и контролировать качество.
Получается, что отраслевые решения нужны или более мелким клиентам (нет штата программистам), либо новым предприятиям, которым нужно быстро и сразу поставить готовую систему?
Спасибо за направление, будут смотреть в онлайне.
>>Со своей стороны могу вам сказать как заказчик - моя оценка, что большинство текущих отраслевых решений сильно >>проигрывают не по методике бизнес-процессов, а по внутреннему качеству реализации. Есть отдельные единицы на >>рынке, но их меньшинство. Поэтому на своей работе мне легче реализовать свое отраслевое решение силами in->>house разработчиков, чем использовать отраслевое.
Если у вас большое предприятие и имеет в штате своих разработчиков, вы скорее всего никогда не купите отраслевое, ведь своё можно сделать как вам нужно без лишнего обвешивания функционала и контролировать качество.
Получается, что отраслевые решения нужны или более мелким клиентам (нет штата программистам), либо новым предприятиям, которым нужно быстро и сразу поставить готовую систему?
(15) maxx, перечитал еще раз - понял что я слишком размыл свой свой совет.
"отраслевым решением может являться маленький отраслевой компонент по цене 1000 рублей"
через 3 года будет комплект отраслевых компонентов, который плавно превращается в отраслевую систему.
В этом случае главное сделать качественно маленький компонент, самый первый.
"отраслевым решением может являться маленький отраслевой компонент по цене 1000 рублей"
через 3 года будет комплект отраслевых компонентов, который плавно превращается в отраслевую систему.
В этом случае главное сделать качественно маленький компонент, самый первый.
Не знаю куда правильнее написать, но хочу высказаться о плохой организации онлайн-трансляции.
Качество изображения не позволяло разобрать ни надписей на скриншотах, ни строчки кода. Оператор вместо ключевых слайдов снимал внимательно слушающий зал, а когда докладчик подходил к флипчарту сразу же переключался на слайд. Периодические проблемы с интернетом, с изображением, микрофонами, постоянная рассинхронизация потока. Некоторое время слушали только звук, картинки просто не было. Второй день третьего потока был вообще печальным. Отличнейшие докладчики, актуальнейшая тема и никакой возможности увидеть что же на слайдах.
Посмотрите методику Стаса Фомина - получаются отличные видео, а не этот трэш.
Ещё момент — неприятно удивило, что видеозаписи конференции надо докупать отдельно. Правда, если качество изображения там аналогичное трансляции, то и смысла нет.
Качество изображения не позволяло разобрать ни надписей на скриншотах, ни строчки кода. Оператор вместо ключевых слайдов снимал внимательно слушающий зал, а когда докладчик подходил к флипчарту сразу же переключался на слайд. Периодические проблемы с интернетом, с изображением, микрофонами, постоянная рассинхронизация потока. Некоторое время слушали только звук, картинки просто не было. Второй день третьего потока был вообще печальным. Отличнейшие докладчики, актуальнейшая тема и никакой возможности увидеть что же на слайдах.
Посмотрите методику Стаса Фомина - получаются отличные видео, а не этот трэш.
Ещё момент — неприятно удивило, что видеозаписи конференции надо докупать отдельно. Правда, если качество изображения там аналогичное трансляции, то и смысла нет.
(17) vabue,
Ещё момент — неприятно удивило, что видеозаписи конференции надо докупать отдельно. Правда, если качество изображения там аналогичное трансляции, то и смысла нет
хм, а где это написано? Предыдущие трансляции были доступны он-лайн в течении месяца или двух. А вообще только на вдумчивый просмотр и надеюсь, т.к. монитор один а секций 3 ...
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот