До начала конференции осталось чуть более 1 месяца. Уже опубликована программа - http://event.infostart.ru/november2013/, ведется активно работа по подготовке докладов.
В этот раз, как вы уже знаете, формат конференции поменялся: теперь в течении 2х дней будет 6 секций различной тематики - по три параллельных секции в течение 1 дня.
Формат самой секции тоже изменен: в первой половине секции будут выступать приглашенные докладчики, во второй половине дня будет проведен Круглый стол по теме секции, на котором докладчики выступят в качестве экспертов.
Экспертам можно будет задавать любые вопросы в рамках тематики секции - как по их докладам, так и любые другие, в том числе ваши насущные вопросы, связанные с реальными практическими задачами.
Мы хотим часть вопросов Круглого стола сформулировать с вами совместно заранее в виде небольших практических кейсов, для чего и создана эта тема форума.
Предлагаем всем заинтересованным пользователям портала Инфостарт предложить свои вопросы/кейсы для секции "Практика внедрения учетных систем" на обсуждение.
На секции будут обсуждаться проблемы внедрения учетных систем, рассмотрены практические вопросы всех этапов внедрения - от планирования проекта до запуска в эксплуатацию.
На докладах приглашенные эксперты - опытные специалисты по внедрению автоматизированных систем учета - расскажут:
О планировании и оценке проекта
Как организуется процесс внедрения на крупных проектах автоматизации
Об управлении содержанием проекта и практическом опыте применения такого инструмента, как 1С:Система проектирования прикладных решений (1С:СППР) для этих целей
О проблемах проектов внедрений, где требуется переход со старой системы на новую и как эти проблемы решаются
(2) AllexSoft, для малых как минимум не практиковать практику оставления письма потомкам "Здесь был Вася " в комментариях. Уже даже будет хорошо, если будут использовать хранилище, еще лучше когда будут делать тесты и еще лучше, когда коммиты в хранилище будут привязаны к задачам в багтрекере и автоматом это будет синхронизироваться (где-то здесь хочется вспомнить "сапожник без сапог" или "автоматизатор без автоматизации").
(2) Давайте сформулируем это в виде вопроса - чем "малые" внедрения отличаются от "больших"?
Что применимо для малых, что нет? Мы не ограничены "масштатабами".
Как масштабировать методики внедрения - это тоже вопрос, укладывающийся в рамки темы.
(4) kuntashov, я работал и на крупных внедрениях с использованием 1С:СППР и целым штатом аналитиков, методистов, программистов, всякого рода архитекторов и тд... в малых объемах это все просто не применимо, даже использовать 1С:СППР нет смысла, проще подойти все объяснить на пальцах человеку кто будет реализовывать данный участок кода
(5) Я полностью согласен, что у подобных инструментов есть своя область применимости с точки зрения целесообразности использования и на малых проектах эффективнее использовать более простые инструменты.
Использование 1С:СППР - это лишь одна из 5 тем докладов.
Еще раз повторю - мы никак не ограничиваем круг вопросов на Круглом столе масштабом проектов.
(2) AllexSoft, для малых как минимум не практиковать практику оставления письма потомкам "Здесь был Вася " в комментариях. Уже даже будет хорошо, если будут использовать хранилище, еще лучше когда будут делать тесты и еще лучше, когда коммиты в хранилище будут привязаны к задачам в багтрекере и автоматом это будет синхронизироваться (где-то здесь хочется вспомнить "сапожник без сапог" или "автоматизатор без автоматизации").
Предлагаю в качестве небольшой темы для круглого стола: "Практика работы с хранилищем конфигурации и администрирование баз 1С". В данной теме затронуть не только хранилище, но и в целом схемы по работе с базами. Некоторые вопросы я поднимал в статье http://infostart.ru/public/189466/. Оттуда же из комментариев есть очень хорошая ссылка http://speshuric.livejournal.com/150114.html.
Интересно как построена технология в больших командах и в маленьких, в случае поддержки огромного зоопарка баз, в случае баз, которые работают 24х7 и тд.
(8) Спасибо, такая тема "на карандаше" - Олег Филлипов изначально планировал более масштабный доклад про организацию работы своей команды, но из-за ограничения по времени и уклона тематики больше в методическую работу, нежели "разработческую", мы из доклада это убрали, но вполне можно затронуть в рамках обсуждения, мы подумаем, еще раз спасибо.
(9) Жень, ты отчасти прав, но на самом деле можно и у нас тему затронуть, просто акцент с технологического аспекта перенести в организационный (организация взаимодействия разработчиков компании-аутсорсера со штатными разработчиками Заказчика по модификации конфигураций: кто какие процессы использует, как зоны ответственности разделяются и т.п.).
Уж сколько раз наблюдаю и вижу, если что и делают, так это для гигантов, корпораций, холдингов. Наполеоны кругом одни! Хоть бы что-нибудь сделали для малого бизнеса.
(23) pumbaE, а почему? На всех фрилансеров не хватит крупных компаний :), а вот работы с малым бизнесом полно. Со временем любой ЧПшник хочет автоматизировать свой бизнес, только вот не знает как :)Я понимаю, что работать проще с заказчиком, которой спец в своем деле и у него команда профи. Который может грамотно составить ТЗ и понять то, что Вы ему предлагаете сверх ТЗ. А спортивный интерес - смогу или не смогу, или забить просто "болт"?
(24) LiliyaM, тема большого холивара. Повторюсь, я не хочу учить малый бизнес думать (они то уже работают, значит думать как то умеют), я не хочу работать по ТЗ от а до я.(24) LiliyaM,
(25)pumbaE, очень жаль,что Вы считаете нашу небольшую переписку бессмысленным спором. Я, как человек, который больше сталкивался с малым бизнесом и смотрел как он постепенно рос, просто хотела услышать мнение человека, который работает с крупным бизнесом. Мне это было интересно...
хотела услышать мнение человека, который работает с крупным бизнесом
вы меня возможно с кем-то спутали, ну или нам с вами надо определиться в градациях мелкий/средний/крупный/большой бизнес.
Просто тема обучения малого бизнеса - это как у педагога обучение учеников, есть те которые хотят учиться и те которым необходимо дать знания. С одними приятно работать, с другими возможно нет.
Жизнь по тех. заданию, тоже холиварная тема, пример от Акулова ТЗ наводит меня на такой риторический вопрос - сколько раз сможет художник под копирку сделать чертежи? Вроде и там и там нужна точность движения кисти, усидчивость, терпение и т.д.
(28) Жень, параллель с художником не очень корректная, если проводить ее с нашей профессией, т.к. художник рисует так, как он сам видит это, и никто и ничто ему не указ.
А мы делаем рабочие инструменты. Мы их не можем делать так, как нам хочется, мы их должны делать так, как это целесообразно с точки зрения назначения этих инструментов.
(29) kuntashov, "А мы делаем рабочие инструменты. Мы их не можем делать так, как нам хочется, мы их должны делать так, как это целесообразно с точки зрения назначения этих инструментов." - золотые слова!!! :)
(29) kuntashov, частично согласен , параллели это не мое, когда я писал у меня было представление, что дай художнику свободу он вместо холста захочет использовать стенку дома или на асфальте нарисовать, ну или портретисту сказали рисуй как хочешь, но вот от левой стороны на расстоянии 3 см и 20 мм должна быть такая линия как-то так. Но в целом согласен, что параллель не ахти. В принципе в любой работе имхо 80% ремесла и 20% творчества, но когда лишают и 20% процентов, тогда уже становиться печально, во всяком случаи для меня.
(30) Но ведь это правда, найдите из всего множества людей, которые просто так хотят учиться, только влияние внешних факторов заставляет человека отложить ipad, встать с дивана начать потреблять полезную информацию и пытаться что-то создавать, а не быть простым потребителем/обывателем. Поэтому, пока есть возможность ткнуть пальцем я тоже буду тыкать в монитор и говорить, что вот здесь так, а здесь по другому. Люди привыкли к вербальному общению и вербальной постановки задачи и пока человек привыкнет к конструктивному письменному общению может пройти очень много времени, заметьте мы уже отвыкли от письменности, проще по скайпу поговорить обсудить, чем нормально описать пожелания/требования/инструкции, но какое время такие и нравы.
(28)Евгений, "Просто тема обучения малого бизнеса - это как у педагога обучение учеников, есть те которые хотят учиться и те которым необходимо дать знания. С одними приятно работать, с другими возможно нет.
Жизнь по тех. заданию, тоже холиварная тема, пример от Акулова ТЗ наводит меня на такой риторический вопрос - сколько раз сможет художник под копирку сделать чертежи? Вроде и там и там нужна точность движения кисти, усидчивость, терпение и т.д." - вот с этим Вашим сообщением я полностью согласна. Просто Вы довольно категорично ответили на (10), что мне захотелось узнать почему?
(10) DoctorRoza, Вот тут я с вами не согласен. Причем координально.
Вот на старой работе мы работали вчетвером - то есть 4 человека это и был весь отдел разработки: и знаете почему мы так и работали вчетвером ? даже когда бизнес рос в 2 раза по обороту, потому что мы подходы как проектного, так софтверного управления применяли даже на маленьком "скрипте-костыле" который чего-то куда-то перегружал.
У нас даже закон был такой - то что не делается за 30 минут = проект. А для проекта все начинается с project scope, ну и т.д.
И в итоге - все просто работало стабильно, с исходными кодами, с автодокументацией по аннотациям к процедурам, с ночными сборками и тестами. И требовало минимум затрат по владению.
Я убежден - что разницы вообще не существует. Что для гигантов, что для малых предприятий.
Не хотите СППР ? Заведите себе Wiki и Канбан доску - подход сохраните, монструозность гиганта уберете.
Во-первых, мы никак не акцентируем внимание на масштабах проектов ни в тезисах, ни в тематике доклада (ну, за исключением одного доклада).
Во-вторых, я полностью согласен с Алексеем Лустиным в (13) - многие правильные методики очень хорошо масштабируются по размеру проекта: просто какие-то шаги методики не используются и т.п.
С инструментами сложнее - но тут опять же сошлюсь на комментарий Леши - инструментов-то как раз полно под разные масштабы проекта.
Поэтому я вам предлагаю, как и выше в (5) AllexSoft, сформулировать, какие именно вопросы "малых" проектов внедрения для вас персонально наиболее актуальны - и мы вынесем эти вопросы на обсуждения в рамках секции.
Это гораздо конструктивнее и, главное, полезнее, чем просто сетование, что опять кого-то обошли стороной, обидели.
(15) kuntashov, мне лично для малых внедерений хотелось бы услышать тему по кейсам внедрений и разработки.. учета времени например, бегтрекер, хранилище... конечно даже для малых задач неплохо было бы иметь небольшую среду проектирования и документирования, чтобы просто не собирать кучу ручных записей в одном месте.. может что то наподобие 1С:СППР в малых масштабах, неплохо было бы рассмотреть возможности подобных решений
(16) Спасибо! Не могли бы вы подробнее описать вашу конкретную ситуацию, ваши частные проблемы, чтобы экспертам задать конкретные вопросы, а не перебирать все возможные гипотетические ситуации?
Приблизительно так:
- Сколько человек в команде (вы, вы + разработчик и т.п.)?
- Какого типа проект: чисто внедренческий, внедрение + небольшие доработки или внедрение + большое количество доработок?
- Участвуют ли в доработках разработчики не из вашей команды (например, аутсорсеры; или разработчики заказчика, если вы являетесь представителем аутсорсера)? Есть ли необходимость взаимодействовать с ними?
(17) kuntashov, работал 7 лет в франчайзи) бывало все конечно...
У меня есть свои 2 конфы которые внедрены на нескольких предприятиях. Труд аутсорсеров не использовали. Проблемы вроде описал в (16), нет тех самых наборов кейсов (по обследованию предприятий, по учету времени, по договорам, по лицензированию), так же нет софта в (16) описал какого для небольших групп (у меня было до 5 чел) или вообще для 1 человека (ведь тоже неплохо было хранить где то свои планы на разработку, требования заказчика, куски которые выполнены и описания к ним и тд)
(18) Ок, на нашей секции в нескольких докладах будет затронута тема, как работать с требованиями и другими артефактами, в том числе кто какие инструменты использует и как (по какой методике, какие процессы выстроили).
По методическим вопросам тоже будет много примеров (обследование, учет времени и т.п.). Приходите на секцию.
(10) DoctorRoza, а под малым бизнесом Вы имеете ввиду небольшую команду программистов или самих заказчиков? Соглашусь с(15)- как минимум один доклад будет посвящен Вашему вопросу. Так что приходите :)
если что и делают, так это для гигантов, корпораций, холдингов.
Впечатление, что делают вроде для "гигантов" - а получается все время как для малых предприятий. И потом начинается "ускорение, гласность, перестройка"... Т.е. срочное наращивание парка "супер"-серверов, оптимизация "что-бы хоть что-нибудь работало" и прочее.
(15) kuntashov,
многие правильные методики очень хорошо масштабируются
Методики никогда не "масштабируются", просто либо есть правильный и грамотный подход к данной нише-проекту-задаче-написанию кода, либо абы-как и авось-чего-нибудь.
(21) LiliyaM,
а Вы готовы обучить малый бизнес думать?
Малый бизнес потому и малый, что сам-по-себе и уникальный. С уникальным подходом, уникальным ведением дела, уникальными бизнес-процессами, уникальными поставщиками и т.д. В этом и сила малого бизнеса, иначе он не будет сущетсвовать. А если б он "тиражировал" сам себя, это будет уже не малый бизнес, а корпорация.
Или Вы считаете, что при внедрении автоматизации достаточно выполнять ТЗ от А до Я и не более?
(51) AlexO, В том все и дело, что малый бизнес УНИКАЛЕН! Вот поэтому с ним интересно работать - к каждому свой подход, постоянно что-то новенькое. Только вот часто сталкиваешься с тем что он доходит до определенного уровня и начинает "топтаться" на месте и не понимать, почему не может двинуться дальше. Вот тут и стоит его немного подтолкнуть, подсказать что и как, помочь наладить учет как товарный, так и финансовый. Конечно, одни это хотят, а другие - нет. Вот для тех кто не хочет - работа только по ТЗ от А до Я, а те, кто стремятся развивать свой бизнес - возможен комплексный подход с долгосрочным сотрудничеством.
Коллеги, программа нашей секции сформирована окончательно, в последний момент 6-м докладом в секцию включили совместный доклад Александра Белова и Юрия Гридунова "Организация эффективного взаимодействия Заказчика и Исполнителя с использованием гибких (Agile) методик".
На предыдущих двух конференциях Александру задавали множество вопросов по его технологии и он на все подробно отвечал, но один вопрос все равно остался открытым - как такая технология, как RMS работает на больших проектах.
На этой конференции для ответа на этот вопрос Александр пригласил представителя своего Заказчика, руководителя проекта внедрения 1С в ОАО "РЖДстрой" Юрия Гридунова.
Предлагаю воспользоваться ситуацией и задать особо насущные вопросы заранее!
Вижу, что тема "малый бизнес VS большой бизнес" очень больная для многих. По сути это практически единственный вопрос, который задали в этом обсуждении более-менее конкретно :)
Мы обязательно поговорим об этом в рамках Круглого стола на нашей секции.
Но разве это единственный вопрос, который было бы интересно обсудить?
да, не плохо было бы для начала определиться с определениями
большой - средний - малый бизнес
и соответственно большие - средние - малые проекты для них :)
тут мне ближе идеи Алексея, что подходы в проектах в идеале должны быть универсальными
отличия исключительно в сроках и ресурсах
чисто имхо
По теме конференции хотелось бы еще такие вопросы затронуть:
"Большой проект: организация процессов и документация" - документация конфигурации, необходимость документирования, возможности, способы , есть ли вообще и пользуется ли кто-нибудь. Как нового человека ввести в курс дела (не пользователя, а программиста). Можно ли использовать справку 1С для создания документации.
"Проблемы переходного периода или как перейти со старой системы на новую" - насколько затягивается проект , без шоковой терапии и вообще возможно ли это. У меня к сожалению проекты, плавно ни разу не перетекали из одного состояния в другое.
Еще мне на прошлой конференции задавали много вопросов о вариантов состояний для задач, workflow перехода из одного состояния в другое. Так вот хотелось бы посмотреть примеры, для различных вариантов "большой" проект и "маленький" проект, заказчик-программист-тестер-тестер заказчика- заказчик и т.д. Методика facebook к сожалению не всегда работает и применима во взаимоотношениях заказчиков и исполнителей.
(37) AlexWhite, я имел ввиду какие бывают стадии у задача (Новая, В работе, Выполненна, Протестированна, Принята, Закрыта) порядок перехода, примеры, когда для ошибки совершенно не важно состояние "принято" и т.д.
Конечно, если смотреть в обобщенном случаи, то для нормальной работы у задач должно быть состояние только "открыта" и задача "закрыта", т.к. для конечного пользователя совершенно не важно, кто сейчас отвечает за проверку или реализацию данной задачи.
Когда-то читал, что в facebook в разработке использует для задач только состояния "открыта" и "выполнена/закрыта" и все, остальное считают никак не влияет на конечный результат.
(40) pumbaE, я тоже, в свое время, с двух статусов для задач начинал - Активная, Решена.
Потом все-равно понадобилось разделить для лучшего контроля:
Активная может быть Открыта (поиск исполнителя) и Выполняется (исполнитель определен, срок установлен, стоимость запланирована).
Решена тоже разделилась на Решена, Отложена, Удалена.
(41) AlexWhite, я и предлагаю такую тему поднять. У кого, какие статусы у задач существуют, порядок перехода между статусами, существующие роли ответственных и т.д.
Наши статусы:
1. Зарегистрирована (это значит только поступила, но никем не обрабатывалась)
2. Активная: в работе, приостановлена (в работе может быть по разным услугам SLA: анализ, написание ТЗ, разработка, тестирование)
3. Закрыта с категориями (решена, отказано в выполнении)
К нашей секции присоединился еще один докладчик - Евгений Шумилов (компания 1С-ИжТиСи) с докладом "Как снизить риски и повысить эффективность проектов перевода сильно модифицированных конфигураций на управляемые формы (на примере перевода конфигурации «Бухгалтерия предприятия» с редакции 2.0 на редакцию 3.0)".
Вопросы "перехода" с релиза на релиз - "болевая точка" подавляющего большинства внедрений со значительным количеством доработок, т.к.
- нужно перенести всю бизнес-логику из старой системы в новую
- проверить ее работоспособность, в том числе и с учетом прав доступа различных пользователей
- сделать это максимально быстро (иначе, пока "переходим", выпустят еще пачку релизов, и снова придется все повторять)
В контексте перехода на Управляемые формы - а это предстоит сделать многим пользователям Бухгалтерии предприятя 2.0 - ситуация обостряется тем, что концепция интерфейса изменилась.
Реально ли выполнить переход быстро и качественно? Обсудим на нашей секции :)
Также напоминаю, что продолжается сбор тем/вопросов для обсуждения во время Круглого стола.
(46) kuntashov, когда выполнили работы и предоставили результат пользователям, то наверное каждый понимает, что если отклонится от сценария работы, то можно найти кучу ошибок неучтенных и которые в целом на работу системы не влияют. Поэтому важно не давать пользователям отклоняться от сценария работы, но пользователи ведь в реальной жизни клацнуть не туда (помним что справку никто не читает), выбрать не то значение и система сломается. Так вот после или перед тем как работы выполнены - просит ли кто-то проверить систему простых пользователей, у тех кто не знает что там находится за вот этой кнопкой? Нужен ли в дальнейшем анализ ожидаемого поведения при доработке и фактического использования...
Например из практики самый частый случай - пользователю должно было быть запрещено определенное действие и при этом этому же пользователю разрешено менять запрет... Когда происходит приме работ чаще про 2 пункт(запрет изменения) забывают.
Вопрос интересный, и думаю, не только к Юрию. Обязательно обсудим, хотя, уверен, тут скорее не ответ конкретный будет, а общее рассуждение, потому что вопрос в большей степени стратегический и не однозначный.
при приемке/после приемки работ стоит ли давать возможность пользователям попробовать систему на "слабо" ?
Все возможные "слабо" должны быть учтены/отсечены еще на этапе разработки. Иначе грош цена такой разработке.
то можно найти кучу ошибок неучтенных и которые в целом на работу системы не влияют.
Да кто вам это сказал?! Если в системе ВОЗМОЖНА ошибка, которую разработчик выявил и оставил "а, нет времени исправлять", это ставит крест на всем конечном результате, как бы он не был хорошо прописан.
Поэтому важно не давать пользователям отклоняться от сценария работы
Важно. Но если у них будет возможность "отклониться" - обязательно отклонятся.
выбрать не то значение и система сломается.
А почему ваша программа позволяет выбрать "не то" значение?!
Так вот после или перед тем как работы выполнены - просит ли кто-то проверить систему простых пользователей, у тех кто не знает что там находится за вот этой кнопкой?
Т.е. сам разработчик не может, "закрыв глаза", понажимать все подряд и предугадать, куда еще можно залезьть в его же программе?
Все возможные "слабо" должны быть учтены/отсечены еще на этапе разработки. Иначе грош цена такой разработке.
вы про малый или большой бизнес говорите? "Нам тут всего один 'крыж' поставить и все !"
Если в системе ВОЗМОЖНА ошибка, которую разработчик выявил и оставил "а, нет времени исправлять", это ставит крест на всем конечном результате, как бы он не был хорошо прописан
давайте уточним какой именно вид ошибок вы и я имеем ввиду... С точки синтаксиса все работает, с точки пользователя, одна не установленная настройка у пользователя в доп. правах может вызвать штрафные санкции у предприятия, т.е. с данной настройкой все работает правильно, без тоже правильно, но результат совершенно не тот который ожидали.
Т.е. сам разработчик не может, "закрыв глаза", понажимать все подряд и предугадать, куда еще можно залезьть в его же программе?
может, но он знает, что может сломаться, но по ТЗ он предполагает, что туда никогда не будут лезть пользователи (у нас ведь ТЗ лаконичное и краткое :) ) и этот же ленивый разработчик инстинктивно никогда не будет туда лезть и сам себя успокаивать - этого в ТЗ не было... Да такие проблемы решают обычно отдельные тестировщики, отдел контроля качества, но где вы видели отдел контроль качества? (у самого вендора только начал зарождаться).
Про любой. И, как уже писал, в России нет "крупного" бизнеса - есть монополии, которые как раз и совмещают "мы богаты - но хотим дешево и сердито".
Т.е. это растолстевшие ларечники, которых допустили к деньгам.
С точки синтаксиса все работает
Должно все работать с точки зрения программы. А если неправильная настройка валит весь учет - господа, а где подробнейшая документация к настройкам? Или мы не про 1С?
но он знает, что может сломаться, но по ТЗ он предполагает
Разработчик не должен только "предполагать", а должен предвидеть и закрыть потенциальные "дырки".
А что ему не оплавичают это - так смотрите выше: заказчик "типа я "крупный бизнес" не понимает и не хочет понимать ничего в силу того, что деньги у него и так есть, а все остальное его не волнует, свой "бизнес" и перспективы в нем он как не умел видеть, так и не будет видеть.
(57) pumbaE, я тоже ошибся, глядя на то, как притормозило 2.0->3.0
но потом понял, что это не из-за качества, а из-за того, что рарус тупо не успевает перевести свои шняги на УФ
(59) pumbaE,
У вас в Украине вообще больше на порядок времени и возможностей писать на 1С действительно полезное, чем в России у всех одноэсников вместе взятых ))
что рарус тупо не успевает перевести свои шняги на УФ
пока переводят - 1С к весне выпустит че-нить очередное фееричное, что поставит крест на сстарых методиках и доработках РАРУС, и косвенно - на УФ.
И весь цикл "но вот в новой версии.." начнется сначала.
До начала конференции остались считанные дни и часы, но все еще можно задать вопросы к докладчикам.
Круглый стол - а в нашей секции под него отведено три 40-минутных сессии общения и дискуссий - будет регламентирован:
Первые 40 минут будут отведены под вопросы и ответы непосредственно по тематике докладов. В том числе затронем те вопросы, которые задавались здесь, в этой ветке форума.
Вторые 40 минут сместим акценты на обсуждение сложных ситуаций управления внедрениями, ошибки руководителей проектов и, главное, на то, как их избежать. Откроется эта сессия Олегом Филипповым. Олег представит на обсуждение мини-кейс на эту тему.
И, наконец, последние 40 минут посвятим обсуждению вопросов, касающихся инструментов, используемых для управления проектами - собственно то, по поводу чего здесь больше всего вопросов. Откроет эту 40-минутную сессию Юлия Кузьмиченко с мини-докладом про ее опыт использования 1С:Документооборота для этих целей, а затем плавно перейдем к обсуждению этого вопроса.
Коллеги, кто участвовал в секции в качестве докладчиков и/или слушателей, прошу высказать ваши замечания или как-то иначе прокомментировать организацию.
Не все прошло так, как ожидалось, но тем не менее, на мой пусть и предвзятый взгляд, мы справились. Следил за количеством человек в зале, на докладах их ни разу не было менее 70 человек, в некоторых случаях было более 100 - это тоже подтверждает в какой-то степени успешность секции.
Формат первой части круглого стола (вопрос-ответ) для такого количества докладчиков оказался наверное не самым удачным, т.к. тема секции довольно общая и доклады слишком разноплановые. Зато вторая и третья части круглого стола, кажется, оказались интереснее.
(65) kuntashov, Саша, как докладчик, хочу выразить тебе огромную благодарность за помощь и подсказки при написании доклада. Общее впечатление от проведения секции - все ОТЛИЧНО, даже не смотря на то, что перед моим докладом был небольшой перерыв, что меня выбило из колеи конкретно :) (волнение сыграло свою роль) и не получилось ответить на все вопросы (это компенсировалось тем, что люди подходили во время обеда и задавали их). Исходя из реакции зала, для себя сделала вывод, что переживала зря - тема по внедрению управленческого учета довольно актуальна. Да и методы, которые наша команда применяла, интересны. Так что, Саш, еще раз - ОГРОМНОЕ СПАСИБО! Ты МОЛОДЕЦ!
(67) Лилия, спасибо большое за лестный отзыв, очень приятно! На самом деле успех секции в большей степени зависел от вас и других докладчиков - все подготовили отличные презентации. Мне было очень интересно все выслушать, несмотря на то, что я имел возможность познакомиться с докладами заранее.
Темы вашего доклада, равно как и других участников, были актуальными, напрасно вы сомневались, но да, до того, пока тебе не начнут задавать вопросы, порой сложно это осознать - сам на первой конференции испытывал мандраж, потому что тема была очень узкая и техническая.
Спасибо вам! Было очень приятно познакомиться и работать с вами над секцией!
(65) kuntashov, на мой взгляд все прошло замечательно :)
секция получилась "дружба народов", докладчики выступали из России, Азербайджана, Беларуси и Украины.
Подходы к внедрению проектов озвучивались очень разные и в этом, считаю, главный плюс секции,
от жесткого документирования каждого шага на проекте до чистого творчества и настройки системы налету под возникающие требования. А это здорово, каждый может выбрать для себя наиболее подходящий вариант.
Присоединяюсь к словам благодарности нашему модератору за полезные советы и помощь в подготовке и проведении секции. Саша, спасибо :)