Вакансия аналитик 1С (сейчас открыта). Почему от программиста 1С мало толку? История моего становления.

Статья будет интересна не только соискателям на вакансию, а и другим пользователям 1С. В ней я делюсь опытом, рассказываю, «как дошел до такой жизни». Также, говорю о распространенном губительном заблуждении, что программист 1С может помочь по любому вопросу.

Пишу данную статью в связи с необходимостью закрыть одну из наших вакансий, но, уверен, что она будет, также, интересна всем пользователям 1С. Ведь, в данной статье я поделюсь частью накопленного “житейского” и профессионального опыта. Что же касается вакансии, то она, так сказать, “сборная” и включает в себя такие должности, как “аналитик 1С”, “постановщик задач 1С”, “руководитель проектов 1С” и “консультант 1С”. Сразу оговорюсь, что в нашем понимании аналитик, вероятно, не то же самое, что под данной должностью могут понимать другие компании, так что прошу не придираться к этому. Также, открыта ли, на данный момент эта вакансия — смотрите в наименовании данной статьи — там я буду оставлять самую свежую информацию по поводу ее актуальности.

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

В общем, как Вы понимаете, все это привлекает множество людей к освоению продуктов 1С. Беда заключается в том, что под специалистами 1С “неискушенные” люди понимают программистов. И, действительно, очень многие новички учатся, именно, на программистов 1С. Да, несомненно, программисты нужны. Без них нельзя сделать чего-нибудь существенного, например, изменить программные алгоритмы под наши нужды. И для рынка, вроде бы, большой плюс, что таких людей достаточно много. Но уже давно бросается в глаза, что рынок ими, явно, перенасыщен. Я не отрицаю, что спрос на подобного рода услуги — громадный, и на кусок хлеба таким людям хватает. Проблема заключается в том, что результаты внедрения такими людьми учета во многих компаниях оставляют желать лучшего. Причем, так можно сказать о любом экономическом ПО, не только об 1С. Программы у людей установлены, а учета, толком, и нет. И все это касается как бухгалтерского, так и управленческого учета. В чем же проблема?

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

Чтобы показать Вам, какое я сам отношения имею к программированию, расскажу немного о себе и о том какой путь я прошел. В 5 лет у меня был компьютер синклер, на котором игры и программы загружались с аудиокассет. В этом возрасте я уже умел немного читать и писать. И вот, в моменты, когда игры мне немного поднадоедали, я разбирался со встроенным в этот самый синклер языком программирования. Более того, когда меня спрашивали в детском саду, кем я хочу быть, я один из немногих, уверенно отвечал, что программистом. Несколько позже, с 13 лет, когда у меня появился современный персональный компьютер, я начал изучал такие языки программирования, как Basic, Pascal, затем, Visual Basic. В 14 лет у меня с друзьями появились, даже, первые коммерческие проекты. А с 16 лет я начал изучать язык программирования 1С версии 7.7. В 17 лет я уже стал сертифицированным программистом по 1С. Так вот, к чему я все это говорю? А к тому, что я с детства любил компьютеры, но не знал, что были и другие, не менее важные,  технические профессии. Видимо, так было не только у меня. Оглянитесь, даже сейчас, того же системного администратора или какого-нибудь консультанта, люди могут продолжать называть программистом.

Но перейдем к сути. Я начал работать как программист 1С в маленькой фирмочке 1С-Франчайзи (она стала франчайзи немного позже, когда я сдал экзамены). Шеф привозил мне задачи по доработке программы 1С, и я их выполнял. Первые пару месяцев, кстати, я думал, что 1С — это просто печатные формочки документов. Даже, не знал, что она умеет учитывать и выводить товарные остатки. Ну, просто мне ничего не объяснили, а сразу начали ставить задачи. А задач на изменение механизма учета остатков, просто поначалу, не было. Почти сразу я почувствовал эйфорию, и что я могу сделать в программе все, что угодно. И, поверьте, что, по сути, любой начинающий программист может почти сразу, тоже, сделать в программе что угодно. Да, дольше, да, допустит больше ошибок. Но если за ним хорошо все проверять и вовремя просить его исправить найденные ошибки, то, поверьте, он все сделает как надо. И, кстати, парадокс заключается в том, что любого, даже, самого лучшего и опытного программиста, все равно, нужно очень хорошо проверять. Дело в том, что, как таковые, стандарты знаний программистов 1С, они-то существуют, но вот воспользовался или нет ими программист, когда делал для Вас ту или иную конкретную доработку — неизвестно. Поэтому, если Вы ставите задачу и принимаете работу, то Вы эти стандарты должны знать еще лучше, чем он сам. Есть, правда, нюансы в написании  кода, с которым сможет работать больше количество пользователей одновременно и у них не будут возникать, так называемые, блокировки. Также, есть нюансы со скоростью выполнения программного кода, когда опытный программист может сильно ускорить работу критического участка в программе. Но все эти нюансы важны, наверное, где-то в 1 случае из 100, и, для большинства поставленных в 1С задач, они не понадобятся. Подробнее мы эти вопросы рассмотрим в следующих статьях.

Теперь, вернемся снова к моему пути. От работы я получал много удовольствия. Так как я был и, наверное, остаюсь, достаточно тщеславным, я уговорил шефа, что буду сам ездить к клиентам и брать у них задачи напрямую. Плохо то, что сделанная мною доработка никогда не сдавалась в один заход. Во-первых, мои программы запускались не с первого раза и не всегда работали у клиента так, как они работали у меня в офисе. Во-вторых, будучи новичком и, общаясь с клиентом, я понимал что-то одно, а клиент хотел чего-то совершенно другого. Так что, иногда, приходилось переделывать задачу, практически, с нуля. В этом плане, было заметно, что когда задачу у клиента брал мой шеф и передавал мне — она намного ближе  подходила к тому, чего изначально хотел клиент. Шеф знал бухгалтерию, предпринимательство и экономику. Я всегда восхищался тем, как клиент мог сказать только 2 слова, а мой шеф уже рисовал из этого всего схему, глядя на которую, клиент довольно и утвердительно кивал головой. Были у нас, конечно, и провалы. В основном это происходило, когда задача стояла не доработать программу, а внедрить типовое решение. Ведь, учитывая, что я не знал бухгалтерию, шеф, тем не менее, отсылал меня “обучать” сотрудников заказчика тому, как вводить данные в программу. И получалось это, как Вы понимаете, из рук вон плохо. Заказчики чувствовали, что я по всем вопросам плавал, да и сидеть с ними и помогать им вводить документы в программу мне, как программисту, который, как супермен, “может все”, казалось очень скучным и “недостойным” занятием. Шеф называл это внедрением, а я ненавидел такие проекты. Несложно догадаться, что в основном, они заканчивались фиаско. Видите, а, казалось бы, человек, умеющий программировать, наоборот, универсален, как многие думают. Он может, вроде бы, и как консультант выступать, а может и что-то доработать… Но не тут-то было!

Отработав ровно 3.5 года, я уволился и стал фрилансером 1С. Размещал свои  резюме на сайтах работ и старался никому из приходящих клиентов не отказывать. В тот период, мною были довольны компании, которые достаточно хорошо знали, чего они хотели. Такие компании ставили мне задачу по доработке торгового учета, а я им помогал улучшить постановку их задачи, думал вместе с ними как лучше это будет сделать. Тогда я называл то, чем я занимался управленческим учетом, но сейчас-то я понимаю, что это была лишь его часть. Так вот, то что я помогал клиентам в постановке задачи — это, по их мнению, называлось “хороший программист”. Если появлялись задачи по бухгалтерскому учету, то я, наоборот, ожидал от бухгалтера, что он скажет, что конкретно нужно сделать и четко распишет все проводки. Потому, для заказчиков бухгалтеров — я уже не считался “хорошим программистом”. Проекты, касающиеся обучения и внедрения мне, к счастью, в этот период не попадались. Как Вы понимаете, у меня, на тот момент, созрела проблема. У меня были серьезные заказчики, которые, как правило, вели и бухгалтерский и  управленческий учет. И я понимал, что мне, желательно, было бы объединится с каким-нибудь специалистом по бухгалтерскому учету. На прошлой работе, как Вы помните, меня в этих вопросах выручал шеф, а здесь я был сам по себе со своими знаниями и не знаниями. Была, конечно, мысль говорить всем, что я обслуживаю только управленческий учет, но понимание того, что для обслуживания бухгалтерского учета клиентам придется привлечь другого разработчика, с которым мне придется потом конкурировать, не особо грела.

На самом деле, период моего фрилансерства — это уже был период, когда я потихоньку начал, так сказать, “эволюционировать” из программиста в аналитика и постановщика задач. Кто-то может, также, “эволюционировать”, наоборот, в более глубокого технического специалиста. Кроме того, чтобы стать постановщиком задач, совсем не обязательно вырастать в него из программиста. У нас, наоборот, даже, больше успешного опыта в том, что люди с нуля становился аналитиками, чем  вырастали из программистов. Как я уже говорил в одной из прошлых статей, когда я был фрилансером, то часто затягивал работы. Вообще-то, получалось, что я за рабочий день объезжал клиентов, с каждым из них более-менее подробно общался о том, как правильно сделать ту или иную задачу и обещал поскорее ее закончить. Вечером приезжал домой очень уставший, и уже был не особо способен программировать. Совмещать общение с клиентом, обдумывание задачи и программирование в один день очень тяжело физически. Как будто мозги совсем на другой лад приходится перестраивать. А на завтра, уже, опять запланированы встречи и т.д. Возможно, к тем же самым клиентам уже по другим вопросам нужно ехать, например, какой-то документ не проводится и т.д. Тогда, кстати, удаленный доступ только появлялся и чаще нужно было мотаться, чем сейчас. И, чтобы исправить любую допущенную ошибку, приходилось ехать к заказчику снова. В общем, получалось, что в рабочее время нужно ездить, а только в нерабочее и в выходные программировать. Кроме этого, мне не давало покоя, что вот я сегодня приехал к этому заказчику, как большой специалист, чуть ли не консультант по бизнесу, а завтра к нему же приехал помочь нажать на одну кнопку. А в это время, я не могу запрограммировать ему очень важную работу, как раз из-за недостатка времени. Этим, кстати, очень страдают программисты, которые работают в торговых или производственных компаниях на полный рабочий день. Они могут что-то разрабатывать, быть полностью погруженными в это, а пользователи их постоянно отвлекают вопросами или звонками. Со временем пользователи уже боятся задавать вопросы, так как программист начинает агрессивно на них реагировать и т.д. Во всяком случае, некоторые клиенты имеют у себя в штате программиста, но, дополнительно, обращаются к нам, так как с ним “невозможно разговаривать” и т.д. И здесь я хочу заметить, что, возможно, как раз срочный мелкий вопрос приоритетнее той задачи, которую программист взял разрабатывать на целую неделю. Просто программисту интереснее возиться с этой задачей. Я сам когда-то допускал такие ошибки и скандалил с заказчиками, не понимая, что я просто неверно оценивал расстановку приоритетов. Уже когда у меня появилась своя компания и я перестал эмоционально участвовать в процессе разработки, то до меня это “дошло”. Есть еще такое понятие, как “неинтересная” для программиста работа. Например, я хорошо запомнил, как один заказчик жаловался, что попросил своего программиста, разумеется, за деньги, помочь внести в программу остатки руками. На что тот ответил “Не жирно ли Вам будет? Сами внесете.” и не стал этого делать. Я лично не понимаю, если заказчик знает цену и готов ее платить, почему он должен не получить услугу?  Чувствуете, вот эту “иллюзию” универсальности программистов?

Поэтому, как видите, программист сам по себе в поле не воин. Чтобы качественно обслуживать заказчика, должно быть, минимум, двое людей, среди которых один разрабатывает каждую конкретную задачу, а другой занимается всеми остальными вопросами. Иначе, заказчик будет получать только один тип услуг по обслуживанию своей программы, а другие типы услуг не будут оказываться. Что входит в остальные вопросы, которыми в нашей компании занимаются аналитики, я буду раскрывать дальше в этой статье.

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

Итак, дальше, в 2005 году по резюме на сайтах работ, меня нашел Олег Горбенко. Он в качестве консультанта обслуживал программы 1С в разных компаниях, но с точки зрения не управленческого, а, именно, бухгалтерского учета. И, так как ему, иногда, приходилось делать некоторые доработки в программах клиентов, а он этого не умел делать сам, то ему нужен был программист. У Олега был и опыт работы главным бухгалтером и, действительно, хорошее знание бухгалтерии. Кстати, напоминаю, если кто не знает, что с того времени, мы с ним партнеры по бизнесу. Я до сих пор помню, как Олег меня поразил на моем же поле, где я считал себя “Богом”… Я его пригласил к одному из своих клиентов по бухгалтерскому вопросу. А я им, как раз, должен был одну доработку сдавать, но, как всегда, затянул по времени. Олег после того, как решил свой вопрос, узнал, что они от меня чего-то ждут, и спросил, мол, а чего Вы ждете-то? Вы же, пока, доработки нет, можете делать в программе вот так и так, а как появится доработка от Юры, будете делать по-другому. Они с радостью согласились, а у меня как от души отлегло. И я тогда всерьез задумался о том, как же так получилось, что я все замкнул на себе, а вопрос так просто решался. В итоге, по этой задаче больше не было никакого чувства вины и срыва сроков. Я не помню, о какой доработке тогда шла речь, но само это чувство облегчения я очень хоршо запомнил. Вот пример того, как я зациклился на самой доработке, а взглянуть на ситуацию чуть шире, чем из роли программиста, чтобы не подводить людей, не мог. Олег тогда открыл для меня какой-то целый новый мир, о котором я не задумывался раньше.

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

На форумах я заметил, что многие программисты-фрилансеры таких людей как Олег называют нахлебниками. Мол, зачем нужен посредник между заказчиком и нами? Мы и сами можем приехать к заказчику, взять задачу и выполнить ее, и заказчику так только дешевле выйдет. Так думают и некоторые “неискушенные” клиенты. А что же происходит на деле? А на самом деле программист приходит к заказчику и говорит: “Я могу сделать все, что угодно. Скажите мне, что сделать”. При этом, программист редко знает программу с точки зрения пользователя. А зачем ему это нужно? Он учится в процессе, на тех задачах, за которые клиенты готовы платить. Так что если программист сознательно не начнет в своей работе выполнять анализ данных, направлять клиента не только по пути доработок, а и по пути обучения, то ничему такому он никогда и не научится. Плюс, некоторые клиенты могут не ценить такую работу, а считать, что стоит каких-то денег только доработка и т.д. Да и редко клиенты задают вопрос, мол, может, мы что-то не так делаем в программе? Чаще всего, они вызывают программиста и говорят — тут у нас не те цифры в отчете, а тут нам надо доработать программу и т.д. В итоге, вместо того, чтобы показать заказчику, где он допустил ошибку в исходных данных, и как ему, возможно, изменить некорректный бизнес-процесс (если он, действительно, некорректен), программист просто, как правило, “ломает” программу по требованию заказчика. Причем, если торговый и управленческий учет, действительно, может нуждаться в доработке, то бухгалтерию, чаще всего, не нужно дорабатывать. У Олега нередко случается, что после других “программистов” приходится ставить клиенту чистую программу, обучать бухгалтеров в ней работать, и, оказывается, о, чудо, им подходит стандартная конфигурация без каких-либо доработок. Например, ни в коем случае нельзя ломать программу дробя план счетов на субсчета или делать другие глобальные изменения. Ведь, программист редко знает, куда какая цифра должна попасть из бухгалтерских счетов в регламентированные отчеты. И, часто, заказчик оказывается разочарован, когда после доработок ни один отчет не формируется правильно, и т.д. Но о проблемах бухгалтерии больше расскажет Олег в своем видео по аналогичной вакансии (https://www.youtube.com/watch?v=MZ2PkYBbbJo), связанной с бухгалтерским учетом. Моя же вакансия связана с торговым, управленческим и финансовым учетом.

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

Аналитик, также, должен понимать, что такое управленческий баланс, управленческий отчет о прибылях и убытках, должен понимать, что такое двойная запись и зачем она нужна. В крайнем случае, мы этому, конечно, обучим. Это только некоторые примеры. Потому, часто, чтобы заказчик остался доволен нашей работой, нужно поднять его осознанность, как в плане финансового учета, так и в плане знания программы. Например, иногда нужно отобразить в Экселе откуда и куда попадут его цифры, или сделать тестовый пример в программе и посмотреть по отчетам, что и куда попадает. Все потому, что заказчик, иногда, придумывает такие методики, которые, если их реализовать в точности, как он говорит — не сойдутся в итоговых цифрах… Как Вы понимаете, программист таким заниматься, вряд ли, станет, а сразу возьмет эти задачи в работу. Аналитик же, получая задачу от заказчика, в любом случае, должен задаваться таким вопросами: “от кого исходит задача (от этого конкретного сотрудника, который ее озвучивает, начальника отдела или руководителя компании)?”, “Какова цель этой задачи на самом деле?”, “Нужно ли ее делать, на самом деле, принесет ли она заказчику ожидаемые результаты”? По поводу последнего вопроса, иногда, руководитель передает нам, заведомо, недодуманную задачу своим подчиненным, а они ее ставят нам. И нам, тогда, приходится пробиваться напрямую к руководителю, чтобы подкорректировать эту задачу, привести ее к логической целостности. Иногда ставится задача расширить учет, сделать больше аналитик в существующих данных. В этом случае, мы обращаемся к людям, которые эти данные должны будут заносить и узнаем их мнение о том, возможно ли это. Допустим, как пример, если сотрудник разносит какие-то данные в документе одной строчкой и данная процедура занимает у него 15 минут, а будет вносить те же данные 20 строчками и это будет у него занимать у него 2 часа. Тут вопрос в том, есть ли у этого сотрудника столько времени. Тогда, руководитель должен решить, что, либо он приказывает сотруднику делать эту дополнительную работу, хоть она и будет отбирать намного больше времени, реорганизует каким-то образом работу этого сотрудника с учетом наших рекомендаций, расширяет штат, либо отменяет эту задачу. Выигрыш для заказчика в том, что это все выясняется еще до того, как он потратил деньги на данную доработку. Опять-же, программист, скорее всего, сразу возьмет данную задачу в работу, не думая о том, смогут ли люди заказчика ею пользоваться. Он искренне будет думать, что это не его проблемы. Что-то вроде “мне сказали, я сделал”. А нам бы хотелось, чтобы заказчик имел результат на все потраченные им деньги, и, если, ему немного не хватает, допустим, организованности, или каких-то специфичных знаний — мы это скомпенсируем своей компетентностью. По этой же причине, мы стараемся никогда не продавать программу сразу, без личной встречи с заказчиком. Но об этом поговорим подробнее в следующих статьях.

Кстати, еще один немаловажный фактор. Не все доработки нужно вносить в программу 1С. Если аналитик видит, что решение поставленной задачи должно быть проведено административным путем, а не с помощью программы, он должен об этом уведомить заказчика. Мне лично ставили, например, задачи в 1С, для которых я  порекомендовал использовать обычный Excel. Данные задачи не были как-то связаны с учетом или с уже существующими в 1С данными. Опять же, здесь идет экономия средств заказчика без негативных последствий в плане удобства работы.

Продолжая данную тему, хочу немного остановиться на том, что если некую задачу можно решить без программирования или с минимальным программированием, то это, как правило, и будет оптимальным решением. Помню, лет в 15, когда я еще программировал на Visual Basic, я хотел внести дополнительный модуль в нашу с другом программу. А он сказал, мол, сам будешь потом исправлять ошибки. Я так обиделся на это и дулся на него несколько дней. А на деле-то, он был прав. Чем больше программного кода, тем больше в нем будет ошибок. Даже, если этот код будет писать супер-опытный программист. Типовые конфигурации протестированы сотнями тысяч пользователей и уже максимально отлажены. Потому, мы стараемся, именно, с их помощью решать вопросы клиентов, а не изобретать велосипеды. А тут, кстати, программисты, как видите, и не нужны. Помните, как я будучи программистом неудовлетворительно с этими задачами справлялся? И, только, если базовым функционалом поставленную задачу никак не решить или она этим функционалом решается неудобно, мы принимаем решение о доработке программы. Для программиста — это парадокс. Его вызывают доработать программу, значит, он должен ее доработать. Программисту кажется, даже, что если он придумает как выполнить задачу без доработки, то заказчик решит, что он ленивый или просто отлынивает от работы. Теперь, немного об оптимальных решениях. Недавно, ко мне приходил человек, хотел устроиться на должность аналитика. Так вот, он хвастался, что был постановщиком задачи разработки конфигурации “с нуля” для фитнес-клуба. Знаете, когда я только начинал, мне казалось, что написать свою конфигурацию с нуля — это очень круто и это могут сделать только очень сильные специалисты. Теперь, я на это смотрю совсем по-другому и считаю, что этот человек, скорее всего, просто принял не оптимальное решение. И намного было бы больше пользы, если бы тот функционал, что он придумал, он реализовал бы как дополнительный модуль для конфигурации “торговля”. Тогда программа умела бы не только то, что он в нее заложил, а и весь базовый функционал типовой конфигурации. Но это же тогда пришлось бы придумать, как увязать возможности этого модуля и типовой функционал. Так вот для этого, как раз, и нужна квалификация. Потому, конфигурации с нуля, в основном, как раз, пишут те, кто не разбирается в типовых конфигурациях. Они просто идут по пути наименьшего сопротивления. Но для заказчика, в перспективе, конфигурация с нуля, как правило, окажется намного более плохим решением, чем дополнительный модуль к существующей типовой конфигурации. Да и когда я показал этому человеку, как мы составляем ТЗ, оказалось, что он его составлял куда более поверхностно (без описания структуры справочников, регистров и т.д.).

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

Вот зачем нужны люди между программистом и заказчиком, ставящие поверхностные ТЗ — мне, конечно, непонятно… Получается, что с ним должен работать особенный и очень крутой программист (а такого ресурса, вообще-то, нехватка), в то время, как, работая по нашей схеме, справится и средний программист. К тому же, я лично ценю ТЗ, написанные таким образом, чтобы его можно было дать, практически, любому программисту, он там все понял и смог это быстро сделать, не отвлекаясь на придумывание неописанных в ТЗ нюансов. Такое ТЗ — это и есть продукт аналитика. Это документ, который реально стоит денег. О том, какие ТЗ стоят денег, а какие — нет, мы еще поговорим в следующих статьях. Опять-же, “хорошие программисты” — это мифические существа и очень ограниченный ресурс. Их очень мало и на всех их не хватает. Потому, когда заказчик мечтает сэкономить, наняв “хорошего программиста”, якобы, универсала, я могу только пожелать ему только удачи. Мой личный опыт в качестве программиста, как и опыт большинства наших заказчиков, которые когда-либо работали напрямую с программистами, говорит о том, что рассчитывать на это не стоит.

Итак, мы подходим к концу. Если Вас вдохновила работа, которую я здесь описал, то скажу, что, скорее всего, на нее подойдет человек с опытом работы финансистом, бухгалтером, экономистом, возможно, логистом и другие… В общем, человек, так или иначе связанный с делопроизводством. Если Вы, наоборот, работали полностью в сфере 1С, это, одновременно, и хорошо, и плохо. Главное, чтобы у нас с Вами совпадали взгляды на “правильное обслуживание клиентов”. Если у Вас нет никакого опыта, но работать все равно хотите, Ваш запрос мы, тоже, рассмотрим. В общем, мы ждем от Вас письмо на email: hr@bsp.com.ua. В письме я ожидаю увидеть пометку, что Вы прочитали данную статью и, также, ожидаю от Вас небольшое сопроводительное письмо о себе и чем Вам нравится данная вакансия + некоторая информация, которую Вы считаете, нам будет полезно узнать о Вас. И, разумеется, в письме, хочу увидеть, также, Ваше резюме в стандартной форме. Обещаю внимательно просмотреть все письма, которые придут.

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

Оплата сдельная. Вы получаете % от выработки. Со временем, Ваш % растет.

Да, и рекомендую заглянуть в видео на подобную вакансию от Олега (https://www.youtube.com/watch?v=MZ2PkYBbbJo). А потом, по ходу, уже решить, какая из двух Вам будет ближе.

Спасибо за внимание!

Юрий Халтин, исполнительный директор ООО «Бизнес Сервис Провайдер».