5 выводов, сделанных за 3 года работы разработчиком 1С
Эта статья будет интересна тем, кто только начинает свой путь и ищет куда податься. В этой статье изложу 5 выводов, сделанных за 3 года работы разработчиком 1С.
Почти три года работаю разработчиком 1С и пришёл скорее из-за нужды. В университетское время я периодически читал различные статьи на Хабре и других ресурсах на тему карьеры в IT. Очень много я натыкался на снисходительность в сторону »1С-ников» и поддался этому влиянию. Связать свою жизнь с IT хотел с детства и в своём регионе периодически следил за вакансиями на Авито и на hh.ru. Было в вакансиях для junior«ов не густо. Вернее их не было. В разделе IT были вакансии с названием программист, но в описании было всё: работа в каких-то программах, базах данных, прокладка кабелей под потолком и обслуживание орг. техники.
В середине 3-его курса попалось объявление на программиста-стажёра 1С, при этом требовались лишь базовые знания программирования: знать что такое циклы, условия, массивы и т. д. Я ухватился за возможность и начал учиться. Это был 2020-ый год и работаю в данной области по сей день. Почти за три года работы сделал для себя несколько выводов. Это только субъективное мнение. Каждый из выводов либо основан на личных наблюдениях, либо будут приведены ссылки на источники.
Вывод 1. В России для разработчика 1С в ближайшие годы будет работа… много работы.
За 2022 год зарегистрировано 242 100 новых коммерческих предприятий. Всем этим предприятиям необходимо программное обеспечение, чтобы вести учёт, осуществлять продажи и соблюдать требования законодательства. Большую распространённость в России получила система 1С из-за ряда причин.
Во-первых, возможность подстроить систему под свои специфические нужды. Фирма 1С выпустила ряд типовых решений, которыми можно решить бОльшую часть возникающих на предприятии вопросов. Например, осуществить продажу на контрольно-кассовой технике (ККТ), оформить приходную накладную, сформировать отчёт по продажам. Однако, у директора может возникнуть желание увидеть множество показателей в одном отчёте или получить возможность сравнивать цены на свой товар с ценами конкурентов. В таком случае обращаются за помощью к разработчикам 1С, чтобы они выполнили определённые доработки.
Во-вторых, фирма »1С» заключает договор с партнёрами, которые называются франчайзи. Они оказывают широкий спектр услуг, начиная с продажи типовых решений и заканчивая доработкой этих самых решений.
В-третьих, есть большое количество обучающих материалов как от самой фирмы 1С, так и со стороны. Всё это на русском и «из первых уст». В «большом» программировании есть мнение, что без английского не стать хорошим программистом. В 1С этот принцип не применим.
В-четвёртых, в связи с последними событиями многие организации переходят с зарубежного ПО на отечественные аналоги. Например, Аэрофлот, Московский метрополитен. Также пару месяцев назад проходил собеседование в международной организации (они себя так позиционировали) и там мне сообщили, что у них сейчас много проектов по переходу с немецкой системы SAP на 1С.
Вывод 2. В небольших франчайзи-фирмах вы будете всесторонне развиваться, но это не для всех.
Мне нравится разработка: писать код, улучшать его, создавать нечто новое. Также нравится работать над сложными задачами. Я считаю, что сложные задачи — это интересные задачи, если это не искусственная сложность. Тут следует сделать оговорку по поводу сложности: под сложностью я здесь понимаю либо что-то действительно сложное, какой-нибудь хитрый алгоритм, либо задача, которая требует продолжительных затрат по времени, от 5-ти «реальных» часов. Под «реальными» часами я имею в виду продуктивные часы, потраченные на решение задачи, а не потерянное впустую время из-за незнания чего-либо или по собственной глупости.
Например, вышел очередной закон, который обязывает всех маркировать обувь. Нужно разобраться в вопросе и внедрить этот функционал. Это сложная задача, но сложность искусственная и потому задача не интересная, клиент от её решения не ощутит пользы (наоборот увеличится объём работы за счёт контроля за марками) и нет никакого удовольствия от работы.
Вот другой пример: есть интернет-магазин на Wordpress с плагином WooCommerce. Этот интернет-магазин активно работает, но в плагине нет никаких отчётов чтобы оценить успешность работы магазина в конкретных цифрах. Зато есть свой API, через который можно подключиться из другой системы, загрузить данные и делать с ними что угодно. Это пример непростой и интересной задачи, которую приятно решать и от её решения есть ощутимая польза для клиента.
Однако в небольшой франчайзи-фирме нужно всё: и писать код, и заниматься настройкой конфигурации, и консультировать пользователей по работе в программе, и администрировать базы данных. Помимо этого периодически приходится быть аналитиком, психологом…
Такой режим работы подразумевает многозадачность, быстрое переключение между задачами. Недавно обнаружил, что это давит на меня. У себя я заметил тягу к углубленной работе. Раньше я этого не осознавал, но сейчас, при чтении книги «В работу с головой. Паттерны успеха от IT-специалиста» Кэла Ньюпорта, пришло осознание.
Вывод 3. У каждого своя зона ответственности, при этом мало кто хочет работать — из-за этого возникают застои в работе.
Работа организации, в которой я работаю, связана с ПО: консультации, настройки, обновления и т. д. Одним словом software. Но есть ещё и вторая часть всей системы — hardware. И в моей практике за эту часть отвечает другая организация, которую в разговорной речи чаще всего называют «сис. админы». Так вот, очень часто попадаются некомпетентные люди, которые не хотят выполнять свою работу и любят перекидывать ответственность, заявляя что-то вроде: «Проблема в вашей программе, у нас всё в порядке».
Со временем с таким поведением людей удаётся справляться, закидывая фактами и задавая прямые вопросы. Но когда только начинаешь работать и ещё не знаешь всех тонкостей, всему веришь. И ищешь проблему на своей стороне. А в сочетании с неопытностью возникает зловещий процесс поиска проблемы, которой нет.
Вывод 4. Нужно уметь расставлять приоритеты.
Свою работу я начал ещё когда учился в университете на последнем курсе. У меня были: учёба в универе, работа лаборантом на кафедре высшей математики, написание диплома, подготовка к ГОСам и работа программистом 1С. Много всего и сразу и удавалось балансировать. Потом я получил диплом и у меня осталась только работа программистом с такой стратегией: поднажать, выполнять все задачи по максимуму и выйти в режим «задача поступила, сделал, отдыхай». Но в эту прекрасную стратегию вмешался один из принципов тайм-менеджмента: задачи никогда не закончатся. Они непрерывно поступают.
Какое-то время я нередко работал по сложному графику: с 9 до 23 часов, с перерывами на поесть, помыться и доехать домой. И ко всему этому на выходных дорабатывал то, что не успел сделать на неделе. Спустя время это привело к перманентной усталости, выгоранию и на данный момент у меня качели: то мне нравится моя работа, то от увольнения меня удерживает только кредит на машину.
Задачи мне поступали напрямую от клиентов и для всех задач у меня был равный приоритет. Все они срочные, важные и все должны быть сделаны в ближайшее время. Так вот это не так. У каждой задачи есть приоритет и нужно уметь его правильно определить, чтобы знать что делать в текущий момент времени. Такой подход позволяет избавиться от переработок, избежать конфликтов с клиентами и в целом чувствовать себя лучше. Наверняка многие слышали про матрицу Эйзенхауэра. Так вот, она работает! Нужно стремиться к тому, чтобы все задачи перетекли в квадрат «Важно, не срочно». Если у вас будет много важных и срочных задач продолжительное время, вы начнёте задыхаться.
Вывод 5. В 1С порой натыкаешься на дикий бред.
Последний вывод, возможно, специфичен для сферы 1С. Регулярно выходят какие-либо новые законы, формы документов, которым нужно следовать. Это приводит нас к необходимости регулярно выполнять обновление конфигураций. Очень часто разработчики допускают ошибки. Иногда появляется ощущение, что программы вообще не тестируются на работоспособность. «Скомпилировалось без ошибок — значит, в релиз!» — вот таков девиз некоторых людей, и это приводит к печальным последствиям. Потом дальше разработчики в течение пары дней выпускают кучу патчей, которые глаза мозолят, когда работаешь со своими доработками. Изменения из этих патчей вносят в следующий релиз, а для следующего релиза обнаруживаются новые ошибки, создаются новые патчи и так до бесконечности. Конечно хорошо что ошибки исправляются, но хотелось бы чтобы релизы выпускали пореже и при этом их хорошо тестировали.
Тут можно возразить, что я должен при обновлении всё проверить, найти проблемы и решить их. Но невозможно проверить всё. Это полуутопическая идея — взять программный продукт, который разрабатывал не ты, и протестировать абсолютно весь функционал, который заложен в программе или которым пользуются пользователи. За часы, потраченные на это занятие, никто не заплатит, и приходится после обновления быть на низком старте и исправлять ошибки в случае необходимости.
Ещё возникают вопросы к документации на сайте ИТС (информационно-технологическое сопровождение, набор документов и инструкций к конфигурациям фирмы »1С»). Она не обновляется годами: пытаешься разобраться в какой-нибудь функциональности, а написанное не соотносится с действительностью.
Эта статья является пробой пера и получались из серии «Наболело». У меня не было цели кого-то оскорбить. Это только наблюдения и я не претендую на безусловную истинность. Буду рад почитать комментариям, которые подскажут что во всём написанном было хорошо, а над чем нужно поработать.
