Если заказчик после передачи работ на проверку сразу говорит, что все хорошо и его все устраивает, то это очень подозрительно! Скорее всего вашу работу он не смотрел или уже отдал переделывать другому спецу. 😉

#приметы #юмор

Как (не) потерять данные при настроенном резервном копировании: ликбез для 1С-ника

В айтишном фольклоре есть хорошая поговорка: «Админы делятся на тех, кто не делает резервные копии (бекапы), и тех, кто уже делает». Опытные админы к этому добавляют: «А еще есть те, кто уже проверяют бекапы».

Осознание этих истин рано или поздно приходит и к спецам, сопровождающим базы 1С.

Как-то утром пришло сообщение от главбуха: «Не работает база 1С бухгалтерии. Висит окно запуска уже час, но ничего не происходит». Иду к системному администратору. Он говорит, что ночью был сбой на серверах (скорее всего, из-за этого и возникла проблема с базой 1С), и резонно спрашивает: «Что будем делать?»

Что за вопрос! Тут и думать нечего. Мы ведь не какие-нибудь безответственные дилетанты, у нас резервное копирование настроено! Предлагаю восстановить базу из ночного бекапа.

Сказано — сделано. Но через некоторое время опять звонит главбух и сообщает, что последние документы в базе — двухмесячной давности…

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

Спрашиваю сисадмина, как такое могло получиться и почему последняя резервная копия такая старая? Он, конечно, ничего вразумительного не отвечает. Зато следом предлагает вместе бекапы проверить.

Предложение отличное, а главное, очень своевременное, думаю я. И судорожно соображаю, что делать. Ищу другие бекапы (при обновлении конфигурации мы делаем дополнительные резервные копии), прикидываю варианты — как еще можно восстановить потерянные данные. Хотя бы частично, например, переносом документов из другой конфигурации.

Составив какой-никакой план, перехожу к следующему важному этапу — продумываю и репетирую траурную речь: «С тяжелым сердцем сообщаю [...]. Документы потерялись так неожиданно, никто не может подготовиться к такому [...]. Но надо жить и работать дальше, восстанавливать учет и годовую отчетность [...]. Вместе мы со всем справимся».

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

Перед тем, как начать восстанавливать данные, я вернулся к сисадмину:
— Как же ты, — спрашиваю, — не заметил, что резервные копии не делаются?
— Так они делаются, — отвечает, — я восстанавливал данные из бекапа от вчерашней даты.
— Это что же получается, во вчерашнем бекапе данные двухмесячной давности?

И тут мы с ним вспомнили, что как раз пару месяцев назад скопировали эту базу на другой сервер. А резервное копирование старой базы никто не отключал. И админ просто перепутал бекапы старой и новой базы (для которой, слава богу, резервное копирование тоже было настроено). Базу мы восстановили. Какую же радость и облегчение иногда можно испытать, решив несуществующую страшную проблему. И при этом не сделав абсолютно ничего полезного. 🙂

Из этой истории я сделал такие выводы:

1⃣ Восстанавливать бекап нужно только в новую базу.
2⃣ Необходимо проверять не только то, есть ли бекап, но и хотя бы иногда смотреть, что лежит в нем и удается ли его развернуть.
3⃣ Если голова не на месте, то никакие бекапы не помогут. 🙂 Когда клиентов, задач и баз становится много, пора заниматься организацией учета не только для клиентов, но и для себя.

Знакома вам потеря данных в 1С?
🔥 — да, было дело, отделались легким испугом.
😱 — сталкивались, даже вспоминать не хочу, чем это все закончилось.
👍 — у нас все четко, таких факапов (тьфу-тьфу-тьфу) не бывало.

Может, хотите что-то добавить из своего опыта?

#истории

Как у вас организовано тестирование разработок?

🔥 – относимся к тестированию серьезно – модульные тесты, сценарные тесты и т.д. для нас обычная практика;
👍 – надеемся на опыт разработчиков, проводим ревью кода менее опытных коллег;
🤔 – в мире 1С лучшие тестировщики – это конечные пользователи!

У вас другой вариант? Напишите в комментариях!

#опросы #юмор

Как-то раз (я был еще совсем молодым программистом) пришлось проводить собеседования с кандидатами на должность оператора ПК в страховой компании. "Ну ты выпиши сюда тех, кто тебе понравился, и чем он тебе понравился", поставил задачу начальник отдела, вручая мне чистый листок и ручку. 🙂

Были у вас ситуации, когда на работе делали не совсем то, что вам полагается по должности?

#юмор

Дедлайн — вчера: как правильно оценить трудоемкость задачи

Каждый 1С-ник сталкивался с оценкой задачи. И, почти уверен, многим доводилось страшно ошибаться не в свою пользу. А потом либо думать, как же согласовать дополнительные сроки, либо изо всех сил стараться уложиться в озвученный вариант (нередко в ущерб качеству).

Что делать? Есть различные более-менее формальные модели (например, COCOMO II), в которых эксперт должен дать оценку количества строк кода в проекте. Исходя из этого высчитывается критерий трудоемкости.

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

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

Есть шуточная формула для получения реальной оценки задачи (Треал) по оценке программиста (Тпрогр):
Треал = Тпрогр ✕ π ✕ e

Формула рабочая, советую 🙂. Но если вам хочется лучшего обоснования, тогда используйте мои наработки (подходит для небольших задач). Они мало помогут с пунктами (а) и (б) из списка выше, но позволят не забыть о важном пункте (в).

Анализ сроков — отдельная тема. О ней в следующий раз.

Ошибаетесь в оценке?
🔥 — часто, но только в свою пользу!
😱 — постоянно недооцениваю реальные трудозатраты и сроки, мучаюсь из-за этого.
👍 — оценкой не занимаюсь, но возьму на вооружение твои наработки, и ух!.. 🙂

#кейсы

Дедлайн — вчера (часть 2): сделаю за один час через два дня

Еще не забыли, о чем был прошлый пост? 🙂 Мы говорили, как оценивать трудоемкость задачи. А что слышно по срокам?

Предположим, вы оценили, что сделаете работу за 16 часов. Но это вовсе не значит, что через два дня клиент получит то, чего так ждет.

Почему нет?
– Спец, который будет работать над задачей, сейчас может быть занят другим проектом. А приступить к новому получится только через несколько дней.
– Спец может взять новую задачу параллельно с другими, тогда у него получится уделять ей только пару часов в день.
– Возможно, часть работы будет выполнять стажер, у которого пока уходит больше времени, чем у его старшего коллеги. К тому же его решение должен будет проверить опытный спец. А он не всегда свободен, не приступит к проверке мгновенно.
– Есть вероятность, что во время работы над новой задачей появятся другие, более приоритетные, на которые придется срочно переключиться. Например, это может быть устранение косяков по каким-то уже сданным работам, которые клиент активно тестирует.
– Имейте в виду: программировать 8 часов в день нереально. По крайней мере я не видел таких монстров, которые могли бы эффективно разрабатывать весь рабочий день. Чаще всего слышал (и мой опыт это подтверждает), что у программиста максимум 4-5 эффективных часов в день.
– В процессе работы над задачей иногда возникают вопросы, требующие уточнения у клиента. Если тот не может оперативно ответить, это тоже увеличивает срок выполнения работ.

При оценке сроков задаемся вопросами:
1. Когда каждый участник проекта сможет приступить к работе?
2. Сколько часов в день они смогут уделять проекту?
3. Из-за чего могут возникнуть задержки?

Я как-то писал, что лучше озвучить дедлайн с запасом и сделать чуть раньше, чем проштрафиться. Если срок в 2-3 раза превышает трудоемкость, обычно у заказчика вопросов не возникает.

Ставьте 🔥, если узнали что-то новое для себя. Ну или 🤓, если давно все это применяете.

#кейсы

Дедлайн — вчера (часть 3): как оценивать большие проекты

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

Как-то меня попросили оценить проект внедрения «Зарплата и управление персоналом» (ЗУП) в холдинге. До этого в настолько крупных задачах я участвовал несколько раз — в роли программиста/консультанта/тимлида. Но полностью все спланировать и оценить еще не приходилось. Это вообще-то работа руководителя проекта, но в тот момент свободных рук не было.

В общем, подошел я к этому делу ответственно. Сразу собрал документы с оценками похожих и не очень проектов. Рассказываю, чем они отличались от небольших задач:

1. План укрупненный, проект разбивается на этапы. Для каждого пункта описаны результаты и критерии приемки.
2. Для каждой задачи указывается количество специалистов по ролям.
3. Оценка чаще всего происходит не в часах, а в человеко-днях.
4. Составляется план-график проекта. Оценка включает не только трудоемкость, но и сроки.
5. Подробно описываются допущения и ограничения. Чтобы заказчик понимал, что будем делать мы, а что должен сделать он, какие факторы могут усложнить проект и сдвинуть сроки.

Более того, составил список проблемных ситуаций, которые возникали у меня и коллег при внедрениях ЗУП. Это помогло скорректировать оценки некоторых этапов (умножить их на π и на e, шучу 🙂), описать допущения и ограничения.

А еще побеседовал с ответственными со стороны заказчика. Обсудили этапы, сроки, сформировали и согласовали итоговый документ. Вот, что получилось (примерно).

При оценке трудоемкости и сроков масштабного проекта вряд ли можно ошибиться в большую сторону. Работает закон Паркинсона: работа будет заполнять все время, на нее отведенное. А чем скромнее бюджет, тем чаще у исполнителя будут возникать причины, почему что-то он сделать не может и не будет.

Документы я отдал руководителю, и вернулся к обычным программистским задачам. А через некоторое время выяснилось, что клиент решился с нами работать. Тут же объявили: раз оценку дал я, то мне за нее и отвечать. Иными словами, пришлось руководить проектом.

Первая мысль — меня подставили 🙂. Хотя рад, что согласился, интересный был опыт. Но это уже другая история, расскажу в следующий раз.

Заметили, что оценка стоимости основывается на времени работы спецов? Традиционный опрос. За какие часы вам комфортнее работать:
👍 — за фактические: сколько отработал, за столько и должен получить. Все по-честному.
🔥 — за плановые: какую сумму с заказчиком согласовали, за такую и работаю. Сделал быстрее — молодец. Промахнулся с оценкой — в следующий раз буду умнее.
🤔 — почасовка не для меня, выдавайте мне оклад вовремя!

#кейсы

Дайджест публикаций за 4 месяца

Оглянулся и понял, что насобирал приличный портфель постов. Хочется напомнить и вам, вдруг что-то пропустили. Для удобства разделил на блоки. Спасибо, что читаете и активничаете, для любого автора это лучший стимул продолжать писать.

Истории из жизни программиста-консультанта. Поучительные и не очень:

🔹 Какой должна быть зарплата, чтобы цифры не влезали в расчетный лист. Увидели, как мелкая доработка может оказаться серьезной проблемой. И поняли, что 1С-ник — это иногда немного дизайнер.

🔹 Как ошибка в интерфейсе может испортить даже очень хорошую программу. Узнали, что Лев Толстой говорил о пользовательском интерфейсе (ну почти).

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

🔹 Всегда ли четкая постановка задачи заказчиком – это хорошо. Сравнили желания заказчика с его потребностями.

🔹 Как (не) потерять данные при настроенном резервном копировании. История о загадочной пропаже двух месяцев учетной информации. Опрос показал, что с потерей данных в 1С многие знакомы не понаслышке.

🔹 Должен ли 1С-ник учить пользователя? Поняли, что путаница в голове у пользователя — беда для 1С-ника. Многие читатели согласились, что учить пользователей все-таки надо.

Советы, кейсы, наработки:

🔸 Что сделать 1С-нику, чтобы заказчик остался доволен. Поговорили о soft-skills. Заметили, что у программистов с ними не всегда хорошо.

🔸 5 недостатков кода, из-за которых его сопровождение превращается в ад. Выясняли как надо и как НЕ надо писать программы. И что делать, чтобы код становился лучше.

🔸 Серия «Дедлайн — вчера». Посмотрели, как оценивать трудоемкость, сроки небольших задач и больших проектов (с примерами). Опрос показал, что многие недооценивают реальные трудозатраты и потом из-за этого мучаются.

🔸 Как предупреждать проблемы с 1С. Рассмотрели, что именно нужно делать, чтобы в жизни спеца и пользователя 1С было меньше стрессов и потрясений.

🔸 Как сообщить 1С-нику об ошибке, чтобы он сразу все понял. Самое простое, сказать: «Ваша программа не работает!» Но есть вариант получше. И он тоже простой.

🔸 Как сделать отличную разработку, и при этом страшно накосячить. Поговорили об ошибках и тестировании программ. Выяснили, почему исполнителю полезно чаще общаться с заказчиком.

🔸 А нужна ли вам автоматизация? Рассмотрели, о чем стоит задуматься перед запуском нового 1С-проекта.

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

🔸 1С или Excel? Читатели считают, что круче 1С. Но я все же предложил свои наработки, позволяющие использовать программы вместе. И рассказал, когда и почему это бывает удобно.

Опросы о наболевшем:

🔻 1С-ник — это тру-программист? Многие считают, что «тру». Высказал мнение о том, откуда вообще возникает такой вопрос.

🔻 Как у вас организовано тестирование разработок? У большинства — пользователями. 🙂 Как ни грустно, но для сферы 1С это норма.


А для тех, кто не особо в теме, но очень хочет разобраться, — мое мнение о причинах популярности 1С.

Что думаете, нужны дайджесты в канале? Помогите определиться:

👍 — да, это как удобная навигация.
🤔 — нет, зачем лишний пост, в котором ничего нового.
🤓 — не знаю, пусть авторы каналов сами этими вопросами задаются.

#дайджесты

Как стать программистом. И надо ли оно вам

В последнее время все чаще вижу, что многие хотят войти в айти. В частности, попробовать себя в сфере 1С. С чего я это взял? Ну, например:

– рассказывают о диком количестве откликов на вакансии начинающих спецов
– реклама курсов Skillbox не лезет разве что из утюга
– в телеграм-каналах тема входа в IT и зарплат вызывает бурные обсуждения.

Приятно, что твоя сфера стала популярна. Но насколько реально в нее попасть? Поделюсь своим мнением.

Успех в освоении программирования практически гарантирован в двух случаях:

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

2. У вас есть хороший наставник, который направляет, мотивирует и поддерживает. Особенно когда после общения с заказчиком вы прикидываете — хватает ли денег на веревку и мыло или все же придется сделать задачу, чтобы еще поднакопить. 🙂

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

Освоение программирования — это долгий путь. Я бы даже сказал, путь длиною в жизнь. Не выйдет поучиться годик-другой и дальше спокойно работать. Профессия подразумевает, что часто придется разбираться с чем-то новым. Хоть бы даже код чужой (и свой) постоянно изучать.

Давайте выясним, интересна ли тема входа в профессию программиста, стоит ли ее развивать здесь:
👍 — валяй, может даже в обсуждении поучаствую.
🤔 — не надо, хватает этого в других каналах.
🤓 — ты автор, ты и думай. А мы почитаем. Может быть.

#мнение_о_важном

Автор канала, 1981 г.

Как стать программистом. Немного обо мне

Чтобы стать хорошим программистом, начинать пить надо с самых ранних лет. Я, конечно, шучу (но это не точно). Просто у меня сегодня день рождения, мне 42! В этом посте решил немного рассказать о себе — в том числе о том, как я стал 1С-ником.

Несколько фактов из детства:

— Родился и вырос на острове посреди моря. Пальмы? Кокосы? Нет, море — Карское, а остров называется Диксон.
— Родители работали в гражданской авиации. В день моего рождения вертолет пролетал над роддомом, и расстрелял весь комплект сигнальных ракет. Многие испугались, уж не началась ли война.
— Компьютерами увлекался с детства. Вот забавная история из того периода. Первая книжка, которую зачитал до дыр, еще не имея компьютера — «Бейсик – это просто»
— Мечтаю научить компьютер программировать. Чтобы было как в известной песне: «Вкалывают роботы, счастлив человек». 🙂

А теперь факты из трудовой биографии:

— Работаю и живу в Ижевске.
— Закончил местный вуз, защитил диссертацию по компьютерной графике.
— Начинал работу админом в небольших организациях. В то время IT-шников не разделяли по специализациям. Так что был «компьютерщиком» – пока прокладывал сеть, осваивал и внедрял бухгалтерию и зарплату 1С 7.7.
— В 2006 году начал работать в 1С-ном ресурсном центре, где меня сдавали в аренду как на большие проекты, так и на мелкие задачи. Здесь произошел самый значительный профессиональный рост — пришлось осваивать большое количество конфигураций, работать быстро, самостоятельно и в разных командах.
— С 2012 года трудился как субподрядчик у франчей 1С, но от своего юрлица. Работа на проектах у франчей интересная, но довольно напряженная. Начал задумываться, как бы работать спокойнее, не теряя в доходе.
— Сейчас с несколькими помощниками сопровождаем своих клиентов. С франчами работаем редко.
— За все время воспитал порядка десяти 1С-ников и много пользователей.

Расскажите в комментариях как вы пришли в 1С? Поздравления принимаются там же 😌.

#истории

А оно мне надо? Кое-что о программировании и качествах спецов

Программист должен обладать способностью первоклассного математика к абстракции и логическому мышлению в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц. Он должен сочетать аккуратность бухгалтера с проницательностью разведчика, фантазию автора детективных романов — с трезвой практичностью экономиста. А кроме того, программист должен иметь вкус к коллективной работе, понимать интересы пользователя и многое другое… (с) Андрей Ершов, академик АН СССР, один из пионеров теоретического и системного программирования

О как! После прочтения невольно задумываешься — а может, ну его... Хотя постойте. На мой взгляд, чтобы успешно программировать, достаточно всего двух качеств — усидчивости и терпеливости. Почему? Давайте посмотрим, чем занимается такой спец.

1️⃣ Изучает ТЗ. Читать придется основательно, при этом задавать уточняющие вопросы и что-то додумывать самостоятельно. Часто нужно переводить с языка пользователя или аналитика на технический 1С-ный, оценивать трудоемкость, сроки. Это уже большая работа, а программировать еще даже не начали.

2️⃣ Пишет и отлаживает код. Обычно это самое интересное. Но ровно до того момента, когда выясняется: твой код не работает, а ты не понимаешь почему. Тогда приходится читать документацию, искать обсуждение похожих проблем в интернете. В конце концов — доставать шаманский бубен. 🙃 Программирование в этот момент становится совсем не таким простым и интересным, каким казалось в уроках курса «разработчик 1С за две недели».

3️⃣ Ищет и исправляет ошибки, которые создал обнаружил пользователь. И не важно, что функционал, в котором возникла проблема, давно сдан и забыт. Да, придется вспоминать и разбираться. Ошибка может крыться в коде, а может и во введенных (или не введенных) пользователем данных. А вдруг это и не ошибка вовсе? Тогда придется доказать, обосновать, а иногда чему-то научить пользователя (желательно без обвинений и мата 🙂). Ничего особенно захватывающего в этой работе нет, зато сил требуется много.

4️⃣ Разбирает и дорабатывает чужой код. Это, на мой взгляд, самая тяжелая работа. Особенно если копаться приходится в легаси-коде — старом, недокументированном, непонятно кем разработанным, к тому же в несопровождаемом стиле. Забавно, но иногда оказывается, что этот «чужой» легаси-код на самом деле твой собственный!

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

🔥 — да, без усидчивости никак (и не только программисту).
🤔 — нет, усидчивость не про 1С-ника. Посмотрите какой ад творится на проектах: у усидчивых и терпеливых такого не бывает!
😱 — прочитал и понял, что не хочу быть программистом!

#мнение_о_важном

Чек-лист самопроверки для начинающего программиста

В прошлом посте мы говорили об усидчивости и терпеливости 1С-ников. Многие согласились, что без этих качеств никак. А можно ли освоить программирование, если усидчивость — не твоя сильная сторона?

Когда-то у меня был подопечный (назовем его Кирилл), которого я с абсолютного нуля учил программировать в 1С. Парень толковый, быстро освоил основы. Я начал давать ему первые реальные задачи и удивлялся скорости, с которой он их решал. Я еще пояснения к заданию договорить не успел, а от Кирилла уже слышал: «Владимир, у меня все готово». Только вот скоро выяснилось: все, что он делает, — работает неправильно или не работает вовсе. 🙂

Почему так получалось?
— ТЗ Кирилл читал по диагонали, и сразу кидался в бой (писать код). Вопросов у него не было, а если и возникали, то ответы он тут же придумывал сам.
— Он был абсолютно уверен, что результат работы программиста — это код, а не работающее решение.
— Пересмотр своего кода (я уже не говорю об изучении чужого) казался Кириллу совершенно пустой тратой времени.

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

Я перестал проверять его решения после каждого «у меня все готово». Вместо этого последовательно задавал следующие вопросы:

🔻 Задание прочитал внимательно?
🔻 И тебе прям все-все ясно?
🔻 А решение сделал по всему заданию, ничего не пропустил?
🔻 Свой код перечитал?
🔻 Он точно соответствует заданию?
🔻 Оформил код правильно, красиво, по стандартам/регламентам?
🔻 А запускал его?
🔻 И как, работает? Проверил?
🔻 А работает как предполагается в задании?
🔻 Если неправильные данные ввести, не валится?

Каждый вопрос надо было проработать и утвердительно на него ответить. Качество решения уже получалось таким, что постановщик задачи при дальнейшей проверке хотя бы не ругался матом. 🙂

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

Кирилл, кстати, сейчас работает в известной торговой компании программистом 1С. Говорил же, все получится!

Как относитесь к самостоятельной проверке результата работы?

👍 — обязательно перепроверяю.
🔥 — сразу делаю все правильно.
🤔 — чукча не читатель, чукча писатель, а проверкой пусть занимается тот, кто за это деньги получает.

#истории #кейсы

Взгляд на 1С со светлой стороны

— Платформа с широчайшими возможностями
— Конфигурации для любого учета
— Креативный вендор, который столько лет все это развивает
— Огромная сеть партнеров
— Множество отличных внедренцев и специалистов
— Благодарные пользователи
— Развивающийся с 1С бизнес

Взгляд на 1С с темной стороны

— Замкнутая ограниченная платформа
— Непонятные конфигурации, которые почти всегда нужно «допиливать»
— Негибкий вендор с давно устаревшими технологиями, политикой лицензирования и т.д.
— Жадные франчи
— По большей части бестолковые внедренцы и прочие 1С-ники
— Вечно недовольные пользователи
— Бизнес лучше развивался бы с другими системами, которые задавлены 1С

Какая сторона вам ближе?

👍 — светлая
🌚 — темная
🤔 — поровну
😐 — пока не определился с лагерем

#опросы

На этом канале еще не было рекомендаций других каналов. И вот первая моя рекомендация: канал “Заметки 1Сницы”. Ведет его Анастасия – практикующий спец по 1С, программист, ментор. Ведет стажировки для начинающих 1С-ников. Пишет про вход в профессию, тонкости работы на позициях 1С-ников, публикует интервью с интересными спецами по 1С, директорами франчей.

Несколько запомнившихся мне постов:
📌 Секрет успеха 1С-ника (и не только)
📌 Должен ли программист знать предметную область и типовые?
📌 Как надо обучать разработке по версии меня
📌 FAQ "Хочу стать программистом, с чего начать?"
📌 Интервью с Алексеем Бояршиновым (директором Корады)

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

Рекомендую к подписке! 🔥

Как выглядит работа над проектом 1С: оценка и подготовка

Недавно начали работу над проектом интеграции 1С со сторонним приложением. В серии постов расскажу про это почти в онлайн-режиме. И даже если вдруг проект закончится факапом — ничего приукрашивать не буду, чесслово 🙂.

Вводные

Заказчик — оптово-розничная компания. Работает в 1С Управление торговлей 11 (УТ 11). Требуется интеграция с мобильным приложением, где клиенты будут оформлять заказы. Приложение в процессе разработки, не на 1С.

Участники проекта

— Представитель бизнеса.
Понимает, как должен выглядеть результат, но не разбирается в технических деталях.
— Штатный ИТ-шник (он же 1С-ник). Знает организацию учета и существующие доработки в 1С заказчика, но не погружен в проект.
— Разработчики мобильного приложения. Хорошо понимают свою часть проекта, но почти ничего не знают об 1С.

Наша задача: реализовать обмен данными с мобильным приложением со стороны 1С.

Оценка проекта

Первая встреча была с представителем бизнеса. Он все объяснил и попросил оценку по трудоемкости и срокам. Само собой, результат нужен был еще вчера 🙂. По моим подсчетам, на проект уйдет 2 недели (80 часов). Из них:
1. Разработка спецификации обмена данными (API) и проработка сценариев обмена — 20 ч.
2. Доработка конфигурации (план обмена, HTTP-сервис в 1С) — 40 ч.
3. Ввод в эксплуатацию — 20 ч.

Оценку второго и третьего этапов дал на свой страх и риск — опирался на опыт похожих проектов. Мы недавно делали интеграцию УТ 11 с сайтом для другой компании, по которой я и прикинул трудоемкость. Срок работ оценил примерно в месяц.

Если по сроку возражений не возникло (хотя результат и нужен был вчера 🙂), то общая стоимость заказчику не понравилась. Он ожидал, что будет раза в два меньше. Договорились стартовать с первого этапа, а дальше сделать переоценку. «Очень надеюсь, что получится дешевле», – озвучил пожелание заказчик.

Работы по первому этапу

Почти две недели изучал базу заказчика, созванивался в Zoom с участниками проекта:
✏️ У бизнеса и ИТ-шника уточнял вопросы по проекту и учету в 1С.
✏️ С разработчиками мобильного приложения обсуждал API и сценарии обмена.

Что выяснилось:
❗ Объектов для обмена оказалось в полтора раза больше, чем я предполагал. Соответственно, вырос и объем работ.
❗ По некоторым объектам требуется обмен в обе стороны (1С → приложение и приложение → 1С). Двусторонние обмены сильно усложняют интеграцию.
❗ Местами учет в 1С «кривой» (так сложилось исторически), исправить его проблематично. Это также добавляет головной боли при обмене данными.
‼️ Самое главное — пока нет базы, в которой будет работать наш обмен. Есть близкий к ней вариант, но риски для проекта все равно остаются, потому что могут появиться критичные изменения.

Здесь с трудоемкостью получилось как в известном анекдоте (расскажу в комментариях). Но есть и позитивный момент!

Структуру сообщений обмена в API удалось максимально приблизить к структуре объектов 1С, что, в свою очередь, существенно облегчило задачу. Все благодаря тому, что разработка мобильного приложения еще идет.

В результате уточненная оценка на второй этап (программирование) практически совпала с моей первоначальной. Ничего не подгонял, правда! Заказчик, кстати, все уже согласовал, хотя дешевле не получилось. А куда деваться, это уже не абстрактное число, все расписано подробно.

Сейчас приступаем к кодированию, ждите продолжение.

Традиционный опрос. Бодаетесь с заказчиками по трудоемкости/стоимости задач?
👍 — торгуюсь с азартом, как на арабском рынке
🔥 — приходится, но мне это дело не нравится
🤔 — не бодаюсь и не хочу.

#истории

Насколько быстро можно освоить программирование в 1С?

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

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

В книге «Гении и аутсайдеры» (написал канадский журналист Малкольм Гладуэлл) утверждается, что для достижения мастерства в любой сфере требуется 10 000 часов практики.

Что такое 10 000 часов? Это пять лет работы по 8 часов в день. По-моему, адекватный срок становления крепкого 1С-ника. Но при условии если:
– вы решаете реальные задачи, получаете «боевой опыт», а не только читаете книги или проходите курсы;
– вы сталкиваетесь с разнообразными задачами в различных конфигурациях, а не клепаете все время печатные формы под Бухгалтерию.

А что поможет вырасти побыстрее?

– Работайте не по 8 часов, а по 12 и без выходных. 🙂 Тогда 10 000 наберете раньше, но в подарок идет выгорание.
– Если у вас есть бэкграунд в программировании или решении учетных задач, считайте, часть пути вы уже прошли. Я, например, когда начал изучать 1С, уже многое знал о компьютерах, написал тонну кода на Pascal/Delphi, С++. И уверенно чувствовать себя в 1С стал гораздо раньше, чем через пять лет практики.
– Можно прибегнуть к помощи наставника, который научит мыслить правильно, подскажет, как решить задачу. Только чтобы не давал готовых решений — это вредно для роста.

Как оцениваете свою обучаемость?
👍 — могу самостоятельно освоить что угодно.
🔥 — легко, если есть хороший курс, учитель или компания.
🤔 — я и так все необходимое знаю, чему мне учиться?

#мнение_о_важном
Просто Про 1С

Самый ценный спец: кто он и как им стать?

Расскажу историю. Все имена в ней вымышлены, совпадения случайны. 🙂

У барина было два работника, которые помогали по хозяйству — Иван и Василий. Как-то раз приходит к барину Василий. Говорит:
— Слушай, барин, я работаю у тебя дольше Ивана, так?
— Так, — отвечает барин.
— И делаю ту же работу, что Иван, так?
— Так.
— Выполняю все твои поручения, не перечу, так?
— Все так, — не в силах сдержать удивление, говорит барин.
— Почему же ты платишь Ивану в два раза больше, чем мне? — вдруг возмущается Василий.
— Хм, — задумался барин. – Видишь, мужик едет на повозке, везет мешки? Сходи, узнай, что в них.
Василий догнал мужика, вернулся и отвечает:
— Везет картошку.
— Хорошо. А продает ее?
Василий снова сбегал к мужику:
— Говорит, что продает.
— Так, а почем продаст?
Василий в третий раз побежал. Возвращается:
— Говорит, за пять рублей мешок.
Тут к барину входит Иван:
— Барин, там мужик из соседней деревни картошку на наш рынок везет. Нам ведь как раз картошка нужна. Продает по пять рублей, но я сторговался до трех. Телега уже во двор заезжает, куда выгружать будем?

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

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

Может показаться, что я говорю: «Ценность Ивана в том, что он не трогает лишний раз начальство». Но это не совсем так. Ценность в том, что его не нужно постоянно контролировать. Он самостоятельный и надежный. А если возникнут проблемы, которые не сможет решить сам, — придет к начальству, сообщит, предложит варианты.

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

Василий. Пытается их решить методом пристального «смотрения» в конфигуратор. Ждет, когда кто-нибудь догадается к нему подойти и спросить — нет ли у него каких-то вопросов. Через какое-то время руководитель, узнав что задача не сделана, таки спрашивает Василия, какие у него проблемы, и помогает их преодолеть. Василий уходит решать задачу на второй круг.
Иван. Гуглит. То, что не помог решить Гугл, не стесняется спросить у коллег. С оставшимися вопросами идет к постановщику задачи, предлагая ему свои варианты решения. Если пропадает постановщик или заканчиваются задачи, не забывает напомнить о себе.

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

Поделитесь мыслями, что еще повышает ценность спеца (не обязательно программиста)?

И еще. Вы больше Иван или Василий? 🙂
👍 — Я Иван, и от помощника такого бы не отказался!
🔥 — Иван, конечно, молодец, но у меня так получается редко.
🤔 — Я Василий, уверен, что каждый должен своим делом заниматься: программист — писать код, постановщик — четко ставить задачи и проверять решение, руководитель — контролировать все вопросы.

P.S. На конференцию Инфостарта меня не взяли, так что продолжаю вещать только для вас! 🙂

#мнение_о_важном

Обычно юмор публикуют в пятницу. Но кто сказал, что ему нет места во вторник! 👻

Всем хорошего настроения!

#юмор

Как выглядит работа над проектом 1С (часть 2): интеграция со сторонним приложением

Продолжаю рассказывать об одном из наших текущих проектов. Начало здесь. А в этом посте делюсь тем, как мы реализуем задачу. Предупреждаю: будут технические детали.

Как вы знаете, мы делаем обмен между 1С и мобильным приложением (не на 1С). В обмене участвуют порядка 15 справочников, документов и регистров. Реализуем HTTP-сервис (запросы/ответы в формате JSON), план обмена для регистрации изменений объектов 1С. Входящие запросы разбираются/проверяются с помощью пакета XDTO.

Пользовательский интерфейс тут не предусмотрен, разве что форма для настроек. Чтобы кодить было не так скучно, разработку делаем во внешней обработке: в модуле объекта — основной код, а в форме — возможность запустить какие-то блоки, чтобы видеть, как код работает (и работает ли вообще 🙂).

Мы, кстати, часто начинаем разработку во внешней обработке (иногда часть функционала там и остается после завершения работы над задачей). Чем это удобно:

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

2. Постоянно запуская код, выполняешь этакое модульно-ручное тестирование. В итоге коду больше доверяешь, ведь своими глазами увидел, что он работает 🙂.

3. Можно быстро набросать и попробовать разные варианты организации данных и кода. Потом выбрать более удобный, а остальные просто выкинуть. На этом проекте попробовали два варианта, один уже в мусорке.

Процесс
Разработку по проекту ведут два человека:
Я: прорабатываю архитектуру, кодирую скелет решения.
Мой помощник: дописывает детали — запросы данных к выдаче, оформление результатов по формату в API и т.д.

Что сделали за три недели
✅ Отработали уже примерно 40 часов по этой задаче, но еще не закончили.
✅ Написали и отладили ~2000 строк основного кода и ~200 вспомогательного (для тестирования основного).
✅ Подготовили тестовую базу, настроили веб-сервер, отдали сервис для тестирования разработчикам приложения, с которым интегрируется 1С.

С какими проблемами столкнулись
❗ Изо всех сил отбиваемся от попыток навязать нам работы, о которых не договаривались. 🙂 Пытаемся перенести их на следующий этап.
‼️ До сих пор не готова база, в которой наш обмен будет работать (писал об этой проблеме еще месяц назад).

В комментариях к прошлому посту спрашивали, нет ли у нас наработок для организации обмена. Оформили их на этом проекте, делюсь.

Скоро, надеюсь, будем запускать обмен в рабочую эксплуатацию, так что продолжение следует.

Как относитесь к выполнению работ, о которых не договаривались?
👍 — чаще делаю, если просят не слишком много.
🤔 — чаще не делаю, если не договоримся об оплате.
🔥 — я и есть тот, кто просит сделать что-то дополнительно. Сложно что ли?

#истории