Нужен ли программист в штате?

[Dracosha Andrew]

Asasa, не, не согласен. Программист должен программировать. Вы не называете бухгалтером кассира только потому, что он имеет доступ к бухгалтерским документам? Или шофёром автослесаря, хотя автослесарь безусловно знает как автомашина заводится? Так, пожалуйста, называйте системного администратора системным администратором, настройщика настройщиком, а программиста программистом.

[Asasa]

Asasa, не, не согласен. Программист должен программировать. Вы не называете бухгалтером кассира только потому, что он имеет доступ к бухгалтерским документам?

Dracosha Andrew, да как бы все правильно Вы говорите. Классически - программист должен быть программистом. Но у нас в России в это понятие вкладывают что угодно. В том числе и мы с Вами.
Кстати я кассира называю бухгалтером. И вот здесь с Вами готов спорить (хотя зачем?..). Ибо кассир, - это работник бухгалтерии и как правило эта должность называется бухгалтер-кассир. Да и чаще всего на этой должности работает человек с бухгалтерским образованием.

[Аноним]

А зачем нужен настоящий "программист", если программа уже есть?

[Asasa]

А зачем нужен настоящий "программист", если программа уже есть?

И я того же мнения. Зачем? Или программы такие, что их обязательно надо дописывать и переписывать? Тогда встает вопрос о таких программах "Сделай сам", к которым как приложение нужен "программист".

[lubezniy]

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

[Asasa]

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

1. Не умоляю заслуги настоящих программистов и подчеркиваю, что это наша элитная братия, которых надо беречь и не загружать их всякой "фигней". Ибо зачастую многие новые возможности, касающиеся именно бухгалтерских программ, можно добавить и штатным образом. Ну если конечно не сидишь на древней левой версии. У нас случаев невозможности использования программ для ведения бухгалтерского и налогового учета не случалось. Бывает, что не совсем просто, не очень красиво - бывает. Но чтобы сразу "программист" - не было.
2. Нормальная программа, поддерживаемая разработчиком, всегда меняется в соответствии с новыми требованиями. И продлевать ежегодно обслуживание не так уж и затратно. И если поменялись условия у самого предприятия - надо просто перенастроить программу в связи с изменившимися условиями. В условиях работающего предприятия это не всегда просто. Но зачем же нам голова дана? Другое дело, если из программы для ведения учета пытаются сделать программу для иных целей. Так при чем здесь эта программа.
У нас был клиент, которому за каким-то фигом надо было считать НДС в модуле зарплата.

[lubezniy]

И если поменялись условия у самого предприятия - надо просто перенастроить программу в связи с изменившимися условиями. В условиях работающего предприятия это не всегда просто. Но зачем же нам голова дана?

Не всё так просто. Гипотетический пример: есть программа складского учёта. На небольшом предприятии с небольшим складом она работала нормально, к ней привыкли. Предприятие расширилось, складские площади увеличились, и руководство решило для упорядочения учёта ввести штрих-кодовую систему обозначения товаров на складе. Для этого было закуплено необходимое оборудование, но программа не поддерживала работу со сканерами штрих-кодов и принтерами - соответствующих модулей не было. Вместе с тем, программа имела возможности для подключения дополнительных сторонних модулей и была снабжена документацией для программистов. Спрашивается: почему бы и не применить в данном случае труд программистов?

[Asasa]

Да конечно, можно и так. Но нам видно повезло с БЭСТом - разработчик (коллектив программистов), как правило срабатывал на опережение и к тому моменту, уже были свои дополнительные модули. Достаточно их было приобрести и использовать штатно.
Вообщем-то огонь можно добыть разными способоми, но я предпочитаю коробок со спичками. Дешево, доступно и не требует высокой квалификации.

[Dracosha Andrew]

Asasa, интересно, а если в вашем коробке не было необходимой функции. Вообще? Никогда. И разработчик не обещает?

[Asasa]

Asasa, интересно, а если в вашем коробке не было необходимой функции. Вообще? Никогда. И разработчик не обещает?

Здравствуйте Dracosha Andrew!
Ну что тут сказать. Мне повезло с разработчиком. Он не обещал, но когда возникала необходимость (и это была реальная потребность, а не "дурь" клиента), и я мог четко и внятно объяснить ему для "чего и почему" - он делал и добавлял это в штатные возможности. То есть то, что Вы хотите от меня услышать - я просил сделать разработчиков
программы.
А когда мы выбирали программу, с которой мы будем работать - мы искали ее не один месяц, пока не дошли до четвертого двора на Литейном. Хотя в то время вся страна "бредила" "Турбо-бухгалтером", "Финансами без проблем" и "1С". А у нас был опыт работы с "Лукой" (старшего брата "1С") и мы поняли, что тема "вечной настройки" - это не наша тема. Но увидев БЭСТ-2, поняли, что вот программа для работы, а не для вечных настроек. И сейчас в программах БЭСТ нет "завиральных" идей, но есть все необходимое для работы бухгалтерии - от бухгалтерского и налогового учета до элементов управленческого. И все это достигается пользовательскими настройками.

А сейчас еще проще - если в коробке нет нужных функций, то мы ее и не берем. Рынок большой - поищем еще. Как руководитель, я не могу зависеть от одного человека, пускай самого гениального программиста. Не дай бог завтра он запьёт или уедет в Америку. Любое решение должно быть тиражируемым, а не индивидуальным. А тиражируемым его может сделать только разработчик.

Всем удач!

[DIR]

Если в "коробке" нет нужных "функций", то офисный программист "функцию" в исполняемый модуль добавить никак не сможет.
Специально поставил кавычки. Прежде чем что-то обзывать функцией, надо сначала объяснить, что вы пожд этим словом понимаете...

[Asasa]

Прежде чем что-то обзывать функцией, надо сначала объяснить, что вы пожд этим словом понимаете...

Да наверное каждый свое. Как и под словом "программист". И я о своем, о женском...

[PiterBest]

Asasa, интересно, а если в вашем коробке не было необходимой функции. Вообще? Никогда. И разработчик не обещает?

Пишем свой плагин на функциях или объектах разработчика.
Язык программирования открыт. Никто не мешает.
Более того уже в интернете выложен механизм как создавать
свои запускаемые модули (EXE) с функциями разработчика,
чтобы поддерживать единый стиль работы в комплексе.
Удобнее когда это сделает разработчик штатно - безусловно.
Но тем не менее....пишем плагины под любой каприз Заказчика

[PiterBest]

то офисный программист "функцию" в исполняемый модуль добавить никак не сможет.

А зачем обязательно в исполняемый?

[DIR]

А вот и еще один товарищ, который под "функцией" понимает что-то свое...

[Аноним]

Лучше бы Вам дать описание Вашего понимания - почему Вы так уверены , что именно Вы имеете правильное определение ?

[Asasa]

А вот и еще один товарищ, который под "функцией" понимает что-то свое...

Надо же, какая многообразная программа БЭСТ. Каждый по-своему ее "выворачивает" и получается ведь. Возвращаясь к началу опроса и учитывая что эта ветка касается БЭСТа, делаю для себя вывод:
1. Программист нужен.
2. Программист - не нужен.
3. Возможны варианты.
А это говорит, что БЭСТ сумел найти ту "золотую середину", где комфортно всем - программистам, внедренцам, бухгалтерам. В детали не углубляюсь.

Удач всем участникам диспута.

[IGM]

Не всё так просто. Гипотетический пример: есть программа складского учёта. На небольшом предприятии с небольшим складом она работала нормально, к ней привыкли. Предприятие расширилось, складские площади увеличились, и руководство решило для упорядочения учёта ввести штрих-кодовую систему обозначения товаров на складе. Для этого было закуплено необходимое оборудование, но программа не поддерживала работу со сканерами штрих-кодов и принтерами - соответствующих модулей не было. Вместе с тем, программа имела возможности для подключения дополнительных сторонних модулей и была снабжена документацией для программистов. Спрашивается: почему бы и не применить в данном случае труд программистов?

Уважаемый, вы в своём уме?
Предприятие выросло из того софта, который у него стоит.
И единственно правильный здесь подход - сменить ПО.
Иначе крындец, полная зависимость от дописок + отсутствие перспективы

[lubezniy]

Уважаемый, вы в своём уме?

Предприятие выросло из того софта, который у него стоит.

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

И единственно правильный здесь подход - сменить ПО. Иначе крындец, полная зависимость от дописок + отсутствие перспективы

Всему своё время. Не каждый же день эти дописки делаются. И, тем более, не каждый день нужно менять ПО.

[DIR]

Лучше бы Вам дать описание Вашего понимания - почему Вы так уверены , что именно Вы имеете правильное определение ?

А где я сказал, что мое определение - правильное? Это у вас глюки, милейший аноним. Я говорю лишь о том, что прежде чем спорить, надо бы определиться с терминологией.

[BDAdmin]

Предприятие выросло из того софта, который у него стоит.
И единственно правильный здесь подход - сменить ПО.
Иначе крындец, полная зависимость от дописок + отсутствие перспективы

Как раз "крындец" более вероятен при смене ПО. Т.к. такие решения не должны приниматься только по той причине, что в базовой поставке программы нет какой-либо функциональности.
Если бы было так, то 1С не получила бы широкое распространение. Хоть и число дописок в конфигурациях, на самом деле сужают перспективу.

[IGM]

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

Читайте внитмательно начальные условия задачи.
Было маленькое предприятие с маленьким складом.
Программа удовлетворяла.
Предприятие расширилось, склад увеличился, потребовались штрих-коды.
Софт перестал удовлетворять.
Вывод - надо менять софт.
Никакие дописки тут не помогут.

Не каждый же день эти дописки делаются. И, тем более, не каждый день нужно менять ПО.

А после того, как в тиражируемый софт залезет местный спец - ПРИДЕТСЯ.


Не всё так просто. Гипотетический пример: есть программа складского учёта. На небольшом предприятии с небольшим складом она работала нормально, к ней привыкли. Предприятие расширилось, складские площади увеличились, и руководство решило для упорядочения учёта ввести штрих-кодовую систему обозначения товаров на складе. Для этого было закуплено необходимое оборудование, но программа не поддерживала работу со сканерами штрих-кодов и принтерами - соответствующих модулей не было. Вместе с тем, программа имела возможности для подключения дополнительных сторонних модулей и была снабжена документацией для программистов. Спрашивается: почему бы и не применить в данном случае труд программистов?

[lubezniy]

Читайте внитмательно начальные условия задачи.

Читал... и даже писал. Дальше что?

Было маленькое предприятие с маленьким складом.
Программа удовлетворяла.
Предприятие расширилось, склад увеличился, потребовались штрих-коды.
Софт перестал удовлетворять.
Вывод - надо менять софт.
Никакие дописки тут не помогут.

Если Вам в 1С на крупном предприятии понадобится дополнительная форма отчётности, отсутствующая в стандартной конфигурации и нужная только Вам, то, по Вашим выводам, 1С нужно менять на что-то ещё, т. к. "софт перестал удовлетворять". Спасибо Вам за такой подход огромное... Я уж лучше предпочту договориться с программистом, чтобы он "нарисовал" мне эту форму в конфигурации - и дешевле, и спокойнее.

А после того, как в тиражируемый софт залезет местный спец - ПРИДЕТСЯ.

Кто сказал, что местный спец полезет в тиражируемый софт? Модуль-то внешний: не заладится - отключим и продолжим работать, а программист хай ошибки ищет.

[BDAdmin]

А после того, как в тиражируемый софт залезет местный спец - ПРИДЕТСЯ.

Залезть в тиражируемый софт....
Как это понять?

Развивающееся предприятие проходит несколько стадий, и для каждого этапа ставить свою программу???
Это разумно, когда сохраняется преемственность, т.е. когда ставятся программы одного разработчика.

Функциональные модули, как правило закрыты, за исключением 1С и ряда систем с открытой логикой.
Править стандартную конфигурацию ( логику ) - чревато проблемами.
Обычно оставляют типовую конфигурацию и либо делают копию "куска программы" и в ней доделывают, либо просто внешним модулем, плагином, обработкой дорабатывают функциональность.

Цена такого решения намного ниже нового софта и время получения результата тоже, но от СПЕЦа, конечно, зависит очень и очень много.

[Tsaranov]

Если совсем правильно, то наверное так: компаниям, не занимающимся разработкой ПО программист не нужен, а если все равно нужен, то тогда все равно не программист

[lubezniy]

Если совсем правильно, то наверное так: компаниям, не занимающимся разработкой ПО программист не нужен, а если все равно нужен, то тогда все равно не программист

Почему? Иногда бывает нужен, но его работы больше разовые.

[Asasa]

Если совсем правильно, то наверное так: компаниям, не занимающимся разработкой ПО программист не нужен, а если все равно нужен, то тогда все равно не программист

Молодец! Прямо в яблочко.

[PiterBest]

Не всё так просто. Гипотетический пример: есть программа складского учёта. На небольшом предприятии с небольшим складом она работала нормально, к ней привыкли. Предприятие расширилось, складские площади увеличились, и руководство решило для упорядочения учёта ввести штрих-кодовую систему обозначения товаров на складе. Для этого было закуплено необходимое оборудование, но программа не поддерживала работу со сканерами штрих-кодов и принтерами - соответствующих модулей не было. Вместе с тем, программа имела возможности для подключения дополнительных сторонних модулей и была снабжена документацией для программистов. Спрашивается: почему бы и не применить в данном случае труд программистов?

Вообще пример действительно гипотетический -ничего общего с практикой.
Это какая же программа не поддерживает работу со сканерами ?
Что там поддерживать ?
А принтера этикеток ? Они же давно хоть из ворда все напечатают ?

Может в даном вопросе стоит говорить о нормальном оборудовании и реорганизации процессов труда и ведения учета на предприятии, а
не кидаться искать программиста или софт хаять, какой бы он там ни стоял ?
Если смотреть глобально, то большинство проблем организационные,
их перекладывают на программистов, ругают софт, пытаются чего-то
там еще (все что угодно, только оставить организацию учета и труда персонала как есть, а сами же при этом говорят - у нас стиль бизнеса меняется....Если меняется, начните с того, что Вы хотите, разберитесь с орг.впросами и когда Вам все будет прозрачо взгляните на то,
чем пользуетесь и главное будьте готовы сами измениться сначала. Вопросы могут быть - но не как в этом примере...)

[PiterBest]

Почему? Иногда бывает нужен, но его работы больше разовые.

К сожалению это тоже не так....
Как говорит Жванецкий
" Ремонт - это не действие, это состояние.
Его никогда нельзя закончить. В него можно только войти или выйти"

Разовая работа влечет за собой периодическую поддержку при изменениях каких-либо условий. Я уже не говорю, что у Заказчиков во время еды аппетит начинает расти

[Elkaby]

Разовая работа влечет за собой периодическую поддержку при изменениях каких-либо условий...

И тогда становишься в зависимость от конкретного этого «специалиста». Кто попадал в такую зависимость, знает - каково ожидать прихода программиста, если работа в бухгалтерии простаивает. Бр-р-р, очень жуткие воспомининия…А «он» придет, опять пишет… пишет… А потом вылавливай его ошибки…