Спасибо Дмитрий за фильм и высказанные мысли. Вывод, цифровизация и стандартизация, это зло для энергетики, но добро для производителей. Ну и да, релейщик учится всю жизнь. Дмитрий, у тебя что-то микрофон фонит.
в 99% вакансий под кодовым названием «Программист 1С» подразумевается, что ты и аналитик и внедренец и консультант и программист, а еще вдогонку и сервер можешь админить ну и в железках само собой разбираешься
Вот мы и докатились до такой нехватки програмистов 1С и не желанием идти в эту тему молодых программистов, что другого выхода, как делать программистов из методистов видимо нету.
Я поддерживаю позицию, что внедренц должен знать программирование, поскольку «спасение утопающих, дело рук самих утопающих».
Вот и я, будучи директором, аудитором и внедренцем, сижу и изучаю программирование 1С. Не от хорошей жизни, а от понимания того, что молодежь в 1С программирование не идет. Одним словом: «доэкономились» на программистах до того, что теперь сами должны программировать.
Теоретически, первые 1С: Проф2 или 6.0 и писались так, что программировать должны сами бухгалтера и экономисты. Но сегодня слышу от программистов, что писать на других языках даже проще, а оплата в разы выше и перспектив в разы больше.
Хотя со стороны предприятия, это предложение звучит так же глупо, как предложение: «Каждый финансовый директор должен знать основы системного администрирования, на этом предприятие сможет сэкономить большие деньги». А ещё ему не плохо былобы быть немного технологом и инженером, это тоже принесёт предприятию большую пользу.
Добрый день! Очень верю что это будет, но что то мне подсказывает, что не очень скоро. Это стоит денег, а оперативники обходятся дешевле, т.к. зп у них очень низкая. Тем более старая электромеханика ещё жива. Так что до пенсии доработаем
«Хорошее лучше чем плохое. Всегда Ваш, капитан очевидность.» Понятно, что при катастрофической нехватке разработчиков это замечательный скил. Но где его взять?
Следующее видео: «зачем программисту разбираться в продукте?» — «чтобы аналитики не ставили идиотские задачи»
Вот не соглашусь! Внедренец и аналитик обязательно должен обладать аналитическим мышлением. А это уже личностное качество, а не навык. Тем более, если он работает в паре с программистом. Это самое продуктивное, если не единственное, эффективное решение для получения качественного результата. По своему опыту скажу: один без другого не сможет выполнить свою работу качественно. Уточню, что внедренец — это спец в той области, где он решает задачи. Он должен быть и рядовым служащим, и технологом, и управленцем. Т.к. аналитик должен видеть цепочки взаимосвязей между действиями и показателями. Всю работу можно описать, а программист это «оформит». Но, как показывает практика, часто не хватает профессионалов, без которых программист мало на что способен. И наоборот, можно достаточно примитивно «накодить», но это будет эффективно работать, если к процессам подойти профессионально. Мне приходилось тесно общаться с разработчиками флексис, т.к. прога была у них уж очень сырая со множеством косяков, ей богу, легче создать удобную экселевскую таблицу, чем в ней работать. Так что, они мне, ой как, должны.
Дорогие друзья! Спасибо, что вы с нами! Команда канала сердечно благодарит наших спонсоров, их прекрасные имена перечислены в этом видео. Также спасибо тем замечательным людям, которые поддерживают канал материально, комментариями, репостами и «лайками». Поддержать наш проект и получить приятные бонусы можно, нажав кнопку «спонсировать» под любым нашим видео, или перейти по ссылке: Поблагодарить авторов канала также можно на ЮMoney: 410018518478251. А мы уже работаем над новыми, интересными видео для вас!
Как же ты прав!!! Прям сильно откликается у меня то, что ты говоришь. Я проходил собеседования с «отличниками» в крутых компаниях, ну такие глупые вопросы задают… Начинаешь спрашивать, а какое это отношение к практике имеет? Ответ, ну как же, если теорию не знаешь как же тебе задачу ставить. И думаешь, как же я уже более 10 лет реальные задачи на 1С решаю без знания того как, например индексы устроены? Я их просто применяю и всё, мне достаточно знать зачем они нужны и как их применить.
Это просто у 1с новое поветрие такое — внутри компании все занимаются всем. В последних интервью Директор продвигал ту же самую идею. У себя, я думаю, надо делать как вам удобнее в соответствии с компетенциями ваших сотрудников их стоимостью и временем. На маленький проект, не требующий серьезной проработки, действительно можно направить универсального спеца, объединяющего в себе и аналитика и программиста. Но если проект большой, то так уже не получится.
Умиляет выражение «незначительные доработки».Ну как говорится «в серьезном деле мелочей не бывает». Я думаю внедрение информационной системы все таки серьезное дело и подход должен быть соответствующим.
Ну допустим есть у нас все таки на проекте такие незначительные задачи на разработку. Алексей предлагает тратить на них время аналитика. А это между прочим высокооплавчиваемый сотрудник, хорошо знающий предметную область, но только на начальном уровне владеющий программированием, потому что он не занимается этим профессионально. Сколько он будет разбираться в коде, правильно ли он его напишет — ну большой вопрос, ведь его программистских компетенций может нехватить для решения задачи. А новички в любом деле (в данном случае для аналитика это программирование), переоценивают свои возможности и приуменьшают сложность задачи. А сколько потом времени потребуется на исправление ошибок, допущенных таким спецом вообще оценить сложно.
В результате получим непонятно как решенную задачу с непредсказуемым временем решения, потому что у неопытного специалиста в любом случае уйдет времени больше чем у опытного. Так что экономия времени от отмены коммуникации между аналитиком и программистом весьма сомнительна.
Ну допустим это не опытный аналитик с начальными знаниями программирования, а такой специалист универсал. Все умеет. Можно ли быть специалистом во всех областях? Наверное можно. Я думаю гении встречаются. Но гений — это исключение и человек не встраиваемый в рабочий процесс. А внедрение — это именно процесс, требующий ежедневной рутинной работы. В обчном же случае, компетенции людей неравномерны. Чем мы ежедневно занимаемся — те компетенции наиболее высоко и прокачаны.
Есть ли выход из ситуации? Как решать простые программистские задачи на проекте? Конечно есть и здесь не нужно придумывать велосипед. В среде программистов давным давно существует градация уровня специалистов: мидл, джуниор, сеньор. Так вот направьте на решение таких задач мидла или джуниора и вопрос будет решен. Если конечно это реально простая задача, а не так показалось аналитику. А то на практике аналитик говорит тебе: «ну тут все просто всего одну формулу поправить». А по факту получается, что надо половину программы переписать.
Нужно ли аналитику изучать программирование — конечно нужно. Нужно изучать вообще все что только возможно. Это хорошо расширяет кругозор и тренирует мозг. Но на работе каждый дожен заниматься своим делом. Именно в этом сила командной разработки. Конвеерный метод производства Генри Форда исходит из того что наибольшая эффективность достигается именно тогда, когда каждый делает только свою специализированную операцию, в которой сильна его компетенция. Я думаю, при внедрении информационных систем эта парадигма как никогда применима.
Очень странное заявление. Возможно со стороны 1С виднее конечно как ERP то же на заводах дорабатывают. Но мне кажется если и есть предприятия внедрившие ERP, но которые ERP не дорабатывали (а есть такие? печатные формы и пара реквизитов документов не в счет, у нас вот сейчас проект мы функционал по НДС дорабатываем, т.к. то что требуется заказчику у 1С даже в ближайших планах нет в реализации), возможно им в реальности хватило бы КА или УТ, а ERP им попросту не нужно было? А данный продукт они купили просто потому-что решение позиционируется как одно из флагманских и оно дешевое (да-да несколько сот тысяч за корп ПО это очень дешево если что). Но на более-менее крупном проекте внедрения того же ERP, аналитику просто некогда заниматься кодингом, а программисту некогда собирать хотелки заказчика, писать ФМ модели, проводить обучение и пр. Да и зачем например специалисту по фин учету, который общается с фин. диром заказчика и т.п. делает БДР, БДДС тратить время на отладку и поиск ошибок например в некорректно работающем функционале бюджетирования, который сломали с очередным релизом? Стоимость часа такого аналитика выше чем программиста, просто факт.
У тинька видимо что то не так с апи, или у меня руки кривые, но никак не получается получать корректно список свеч за временной промежуток. Как бы не пытался, но доспустим 5-ти минутные свечи ни разу не удалось получить
Вывод, цифровизация и стандартизация, это зло для энергетики, но добро для производителей.
Ну и да, релейщик учится всю жизнь.
Дмитрий, у тебя что-то микрофон фонит.
Я поддерживаю позицию, что внедренц должен знать программирование, поскольку «спасение утопающих, дело рук самих утопающих».
Вот и я, будучи директором, аудитором и внедренцем, сижу и изучаю программирование 1С. Не от хорошей жизни, а от понимания того, что молодежь в 1С программирование не идет.
Одним словом: «доэкономились» на программистах до того, что теперь сами должны программировать.
Теоретически, первые 1С: Проф2 или 6.0 и писались так, что программировать должны сами бухгалтера и экономисты.
Но сегодня слышу от программистов, что писать на других языках даже проще, а оплата в разы выше и перспектив в разы больше.
Хотя со стороны предприятия, это предложение звучит так же глупо, как предложение: «Каждый финансовый директор должен знать основы системного администрирования, на этом предприятие сможет сэкономить большие деньги».
А ещё ему не плохо былобы быть немного технологом и инженером, это тоже принесёт предприятию большую пользу.
Понятно, что при катастрофической нехватке разработчиков это замечательный скил. Но где его взять?
Следующее видео: «зачем программисту разбираться в продукте?» — «чтобы аналитики не ставили идиотские задачи»
Умиляет выражение «незначительные доработки».Ну как говорится «в серьезном деле мелочей не бывает». Я думаю внедрение информационной системы все таки серьезное дело и подход должен быть соответствующим.
Ну допустим есть у нас все таки на проекте такие незначительные задачи на разработку. Алексей предлагает тратить на них время аналитика. А это между прочим высокооплавчиваемый сотрудник, хорошо знающий предметную область, но только на начальном уровне владеющий программированием, потому что он не занимается этим профессионально. Сколько он будет разбираться в коде, правильно ли он его напишет — ну большой вопрос, ведь его программистских компетенций может нехватить для решения задачи. А новички в любом деле (в данном случае для аналитика это программирование), переоценивают свои возможности и приуменьшают сложность задачи. А сколько потом времени потребуется на исправление ошибок, допущенных таким спецом вообще оценить сложно.
В результате получим непонятно как решенную задачу с непредсказуемым временем решения, потому что у неопытного специалиста в любом случае уйдет времени больше чем у опытного. Так что экономия времени от отмены коммуникации между аналитиком и программистом весьма сомнительна.
Ну допустим это не опытный аналитик с начальными знаниями программирования, а такой специалист универсал. Все умеет. Можно ли быть специалистом во всех областях? Наверное можно. Я думаю гении встречаются. Но гений — это исключение и человек не встраиваемый в рабочий процесс. А внедрение — это именно процесс, требующий ежедневной рутинной работы. В обчном же случае, компетенции людей неравномерны. Чем мы ежедневно занимаемся — те компетенции наиболее высоко и прокачаны.
Есть ли выход из ситуации? Как решать простые программистские задачи на проекте? Конечно есть и здесь не нужно придумывать велосипед. В среде программистов давным давно существует градация уровня специалистов: мидл, джуниор, сеньор. Так вот направьте на решение таких задач мидла или джуниора и вопрос будет решен. Если конечно это реально простая задача, а не так показалось аналитику. А то на практике аналитик говорит тебе: «ну тут все просто всего одну формулу поправить». А по факту получается, что надо половину программы переписать.
Нужно ли аналитику изучать программирование — конечно нужно. Нужно изучать вообще все что только возможно. Это хорошо расширяет кругозор и тренирует мозг. Но на работе каждый дожен заниматься своим делом. Именно в этом сила командной разработки. Конвеерный метод производства Генри Форда исходит из того что наибольшая эффективность достигается именно тогда, когда каждый делает только свою специализированную операцию, в которой сильна его компетенция. Я думаю, при внедрении информационных систем эта парадигма как никогда применима.
если и есть предприятия внедрившие ERP, но которые ERP не дорабатывали (а есть такие? печатные формы и пара реквизитов документов не в счет, у нас вот сейчас проект мы функционал по НДС дорабатываем, т.к. то что требуется заказчику у 1С даже в ближайших планах нет в реализации), возможно им в реальности хватило бы КА или УТ, а ERP им попросту не нужно было? А данный продукт они купили просто потому-что решение позиционируется как одно из флагманских и оно дешевое (да-да несколько сот тысяч за корп ПО это очень дешево если что). Но на более-менее крупном проекте внедрения того же ERP, аналитику просто некогда заниматься кодингом, а программисту некогда собирать хотелки заказчика, писать ФМ модели, проводить обучение и пр. Да и зачем например специалисту по фин учету, который общается с фин. диром заказчика и т.п. делает БДР, БДДС тратить время на отладку и поиск ошибок например в некорректно работающем функционале бюджетирования, который сломали с очередным релизом? Стоимость часа такого аналитика выше чем программиста, просто факт.