Довольный заказчик? Сложно, но можно: делюсь лайфхаками
Насколько проще было бы писать программы, если бы не заказчики. (с) Роберт Мартин, автор книг о разработке ПО
Чего хотят заказчики? «Ну что за вопрос, Владимир!» — скажете вы. Понятно: чтобы работу сделали быстро, качественно и дешево. Но это рациональные факторы. А вот быть довольным чем-то — это, скорее, из области эмоционального. Что конкретно должен делать спец по 1С, чтобы клиент остался в восторге? Даю практические советы — все из личного опыта.
1. Оправдывать ожидания. Или даже немного их превосходить. Но не обещайте клиенту лишнего и старайтесь проговаривать все детали проекта.
🔵 Обсуждаете задачу? Обозначьте (а лучше распишите), что конкретно планируете сделать. Не жалейте на это времени. Зачастую недопонимание между заказчиком и спецом начинается с мысли «ну, это и так понятно».
🔵 Согласовываете сроки? Учитывайте, что в процессе работы многое может пойти не так. Лучше озвучить дедлайн с запасом и сделать раньше (приятно удивив клиента), чем пообещать и проштрафиться. Если в процессе работы подразумевается активное участие заказчика (дать доступы, уточнить сложные вопросы), то сроки зависят не только от вас. Сколько времени клиент готов выделить на проект? Это тоже стоит обсудить на берегу.
🔵 Договариваетесь об оплате? Очертите границы: что входит в стоимость, а что вы будете рассматривать как дополнения и хотелки.
2. Чаще контактировать. Да, для некоторых спецов это бывает сложно. Программисты не любят общаться с заказчиками, говорю по личному опыту 🙂. Но это полезный навык. А как иначе расположить к себе человека и показать, что вы хотите ему помочь, а не просто сделать работу по ТЗ, получить деньги и забыть?
🔵 Есть несколько вариантов решения задачи? Почему бы не обсудить их с заказчиком, показав, что его мнение важно. Но не переборщите с уточнениями, чтобы человек не подумал, что он все делает за вас.
🔵 Часть работы сделана и ее можно показать? Продемонстрируйте промежуточные результаты, соберите замечания и предложения. Заказчик увидит, что работа идет и вы стараетесь сделать ее максимально классно. А к моменту сдачи клиент будет четко представлять, что получит. Результат не станет для него большим сюрпризом, по которому возникнет куча вопросов и замечаний.
🔵 После сдачи работ пользователи нашли ошибки? Отличный повод еще раз связаться, вместе посмотреть, где возникли проблемы. Посочувствовать пользователю, если он расстроен, и проговорить, как и когда планируете все исправить. Только не забудьте 🙂.
3. Делать красиво. Это я об интерфейсе. Красивый код тоже важен, но пользователь вряд ли его увидит и оценит. А вот интерфейс — это как раз то, с чем человек непосредственно имеет дело. И если внешний вид оставляет приятное впечатление, то небольшие косяки, которые заказчик, возможно, найдет позже, сильно уже не огорчат. Ведь первое впечатление — самое важное. А если визуальная составляющая и удобство вашего решения не очень (как у меня это было здесь), то и хороший функционал уже не радует.
Бонус для опытных спецов. Если хотите работать с клиентом долго и счастливо, старайтесь делать то, что ему нужно, а не слепо следовать тому, что он просит (об этом писал здесь). Понимание реальных проблем клиента и искреннее стремление помочь очень подкупает.
Расскажите в комментариях о ваших взаимоотношениях с заказчиками. Есть ли такие, с кем не удается контакт наладить? Может быть есть свои приемы "сделать клиенту хорошо"?
#кейсы
Насколько проще было бы писать программы, если бы не заказчики. (с) Роберт Мартин, автор книг о разработке ПО
Чего хотят заказчики? «Ну что за вопрос, Владимир!» — скажете вы. Понятно: чтобы работу сделали быстро, качественно и дешево. Но это рациональные факторы. А вот быть довольным чем-то — это, скорее, из области эмоционального. Что конкретно должен делать спец по 1С, чтобы клиент остался в восторге? Даю практические советы — все из личного опыта.
1. Оправдывать ожидания. Или даже немного их превосходить. Но не обещайте клиенту лишнего и старайтесь проговаривать все детали проекта.
2. Чаще контактировать. Да, для некоторых спецов это бывает сложно. Программисты не любят общаться с заказчиками, говорю по личному опыту 🙂. Но это полезный навык. А как иначе расположить к себе человека и показать, что вы хотите ему помочь, а не просто сделать работу по ТЗ, получить деньги и забыть?
3. Делать красиво. Это я об интерфейсе. Красивый код тоже важен, но пользователь вряд ли его увидит и оценит. А вот интерфейс — это как раз то, с чем человек непосредственно имеет дело. И если внешний вид оставляет приятное впечатление, то небольшие косяки, которые заказчик, возможно, найдет позже, сильно уже не огорчат. Ведь первое впечатление — самое важное. А если визуальная составляющая и удобство вашего решения не очень (как у меня это было здесь), то и хороший функционал уже не радует.
Бонус для опытных спецов. Если хотите работать с клиентом долго и счастливо, старайтесь делать то, что ему нужно, а не слепо следовать тому, что он просит (об этом писал здесь). Понимание реальных проблем клиента и искреннее стремление помочь очень подкупает.
Расскажите в комментариях о ваших взаимоотношениях с заказчиками. Есть ли такие, с кем не удается контакт наладить? Может быть есть свои приемы "сделать клиенту хорошо"?
#кейсы
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🔥6❤1❤🔥1
Учить пользователя или не учить, вот в чем вопрос
Меня два раза спрашивали (члены Парламента): «Скажите на милость, мистер Бэббидж, что случится, если вы введете в машину неверные цифры? Cможем ли мы получить правильный ответ?» Я не могу себе даже представить какая путаница в голове может привести к подобному вопросу. (с) Чарльз Бэббидж, английский математик, изобретатель первой аналитической вычислительной машины
Путаница в голове у пользователей — это беда для 1С-ника. Но кому, как не нам, этот клубок распутывать? Однажды звонок: «Владимир, в нашей 1С ошибка. Остаток товара в программе не совпадает с реальным остатком на складе. Можешь разобраться, в чем дело, и исправить?»
Я, признаюсь, даже опешил. Значит, вы там косячите (или в 1С, или на складе), а ни в чем не повинный спец должен ваши косяки искать и исправлять?! Впрочем, это я так подумал. А сказал следующее: «Ладно. Только давайте сначала вместе посмотрим эту проблему».
Начали разбираться. Вот, что выяснили:
🖇 Остаток по проблемной номенклатуре по всем регистрам («Товары на складах», «Товары организаций», «Свободные остатки») и правда отличается от того, что насчитал кладовщик.
🖇 Остаток мог «разъехаться» по дублям. Но дублей номенклатуры нет.
🖇 С итогами регистров тоже порядок, пересчитали.
Я даже начал показывать, как оформить инвентаризацию. Но внезапно до меня дошло, что проблема не в 1С, а в пользователе. Дальше диалог:
— Может, — говорю, — вы документ какой-нибудь забыли ввести?
— Нет, — отвечает пользователь, — мы все аккуратно вводим.
— А давайте, — предлагаю, — посмотрим ваши документы.
Оказалось, что часть документов просто-напросто не проведены, а висят черновиками.
— Ну да, — признается пользователь, — там какие-то ошибки возникали, мне посоветовали, что в этом случае можно нажать кнопку рядом с «Провести». Называется она — «Записать».
Я даже не стал уточнять, кто ему это посоветовал! Но решил потратить полчаса на ликбез по основным принципам и понятиям работы в 1С. А параллельно для себя понял, что 1С-ник должен быть не только немного дизайнером (о чем писал здесь), но инемного много учителем. Кто бы мог подумать, что программисту может пригодиться опыт в педагогике (кстати, я даже преподавал у студентов, пока учился в аспирантуре).
Давайте устроим голосование:
🔥 — Если считаете, что лучше потратить время на обучение пользователя: так он будет понимать, что делает, и сумеет правильно сформулировать свои запросы.
🤔 — Если убеждены, что не наше это дело — пользователей учить, а часы на решение несуществующих проблем все равно оплатят.
#истории
Меня два раза спрашивали (члены Парламента): «Скажите на милость, мистер Бэббидж, что случится, если вы введете в машину неверные цифры? Cможем ли мы получить правильный ответ?» Я не могу себе даже представить какая путаница в голове может привести к подобному вопросу. (с) Чарльз Бэббидж, английский математик, изобретатель первой аналитической вычислительной машины
Путаница в голове у пользователей — это беда для 1С-ника. Но кому, как не нам, этот клубок распутывать? Однажды звонок: «Владимир, в нашей 1С ошибка. Остаток товара в программе не совпадает с реальным остатком на складе. Можешь разобраться, в чем дело, и исправить?»
Я, признаюсь, даже опешил. Значит, вы там косячите (или в 1С, или на складе), а ни в чем не повинный спец должен ваши косяки искать и исправлять?! Впрочем, это я так подумал. А сказал следующее: «Ладно. Только давайте сначала вместе посмотрим эту проблему».
Начали разбираться. Вот, что выяснили:
Я даже начал показывать, как оформить инвентаризацию. Но внезапно до меня дошло, что проблема не в 1С, а в пользователе. Дальше диалог:
— Может, — говорю, — вы документ какой-нибудь забыли ввести?
— Нет, — отвечает пользователь, — мы все аккуратно вводим.
— А давайте, — предлагаю, — посмотрим ваши документы.
Оказалось, что часть документов просто-напросто не проведены, а висят черновиками.
— Ну да, — признается пользователь, — там какие-то ошибки возникали, мне посоветовали, что в этом случае можно нажать кнопку рядом с «Провести». Называется она — «Записать».
Я даже не стал уточнять, кто ему это посоветовал! Но решил потратить полчаса на ликбез по основным принципам и понятиям работы в 1С. А параллельно для себя понял, что 1С-ник должен быть не только немного дизайнером (о чем писал здесь), но и
Давайте устроим голосование:
🔥 — Если считаете, что лучше потратить время на обучение пользователя: так он будет понимать, что делает, и сумеет правильно сформулировать свои запросы.
🤔 — Если убеждены, что не наше это дело — пользователей учить, а часы на решение несуществующих проблем все равно оплатят.
#истории
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥36👍12🤔7❤2
1С-ник — это тру-программист?
Или… Ну, такой… Как на иллюстрации? 🙂
На первый взгляд, вопрос кажется не сильно серьезным. Но я знаю, что из-за опасений на этот счет некоторые молодые и перспективные ребята боятся идти в мир 1С. А для продвинутых спецов это один из аргументов в пользу перехода на другие технологии и языки.
А почему, собственно, такой вопрос возник? Я напишу свое мнение, а в комментариях хотел бы узнать ваше.
1. Предубеждения относительно программирования на русском языке. Да, у встроенного языка 1С есть русский синтаксис. К слову, английский тоже есть. Но в основном пользуются именно русским. И это по-началу непривычно для тех, кто программировал на чем-то другом.
2. Замкнутость экосистемы 1С. О чем, например, Java-программист может поговорить с 1С-ником? Об особенностях веб-фреймворков*? Или о том, какая IDE** лучше? Большинству 1С-ков эти темы не актуальны. А Java-программист слыхом не слыхивал про «конфигуратор» или «управляемые формы». Но при этом спецам по Java и С++ проще найти общие темы для разговора.
3. Низкие требования к технической подготовке 1С-ника. Бытует мнение, что 1С-ник должен знать предметную область учета (бухгалтерию, зарплату или производство), но ему не нужно быть подкованным в технической части разработки ПО. Ведь кажется, что встроенный язык 1С простой. Да от него многого и не требуется для решения задач «этих ваших учетов». С таким мнением я согласен лишь отчасти.
Предлагаю очередное голосование:
🔥 — если считаете, что 1С-ник – тру-программист.
🤔 — если сила 1С-ника точно не в программистских навыках.
Если вы не айтишник — напишите, слышали что-то про обсуждаемую в посте дилемму? Или только программисты этим загоняются? 🙂
#опросы
Или… Ну, такой… Как на иллюстрации? 🙂
На первый взгляд, вопрос кажется не сильно серьезным. Но я знаю, что из-за опасений на этот счет некоторые молодые и перспективные ребята боятся идти в мир 1С. А для продвинутых спецов это один из аргументов в пользу перехода на другие технологии и языки.
А почему, собственно, такой вопрос возник? Я напишу свое мнение, а в комментариях хотел бы узнать ваше.
1. Предубеждения относительно программирования на русском языке. Да, у встроенного языка 1С есть русский синтаксис. К слову, английский тоже есть. Но в основном пользуются именно русским. И это по-началу непривычно для тех, кто программировал на чем-то другом.
2. Замкнутость экосистемы 1С. О чем, например, Java-программист может поговорить с 1С-ником? Об особенностях веб-фреймворков*? Или о том, какая IDE** лучше? Большинству 1С-ков эти темы не актуальны. А Java-программист слыхом не слыхивал про «конфигуратор» или «управляемые формы». Но при этом спецам по Java и С++ проще найти общие темы для разговора.
3. Низкие требования к технической подготовке 1С-ника. Бытует мнение, что 1С-ник должен знать предметную область учета (бухгалтерию, зарплату или производство), но ему не нужно быть подкованным в технической части разработки ПО. Ведь кажется, что встроенный язык 1С простой. Да от него многого и не требуется для решения задач «этих ваших учетов». С таким мнением я согласен лишь отчасти.
Предлагаю очередное голосование:
🔥 — если считаете, что 1С-ник – тру-программист.
🤔 — если сила 1С-ника точно не в программистских навыках.
Если вы не айтишник — напишите, слышали что-то про обсуждаемую в посте дилемму? Или только программисты этим загоняются? 🙂
#опросы
🔥52🤔11👍7❤2
Как предотвратить проблемы с 1С и упростить жизнь пользователю и спецу
Болезнь легче предупредить, чем лечить — слышали такое? Это применимо и к ИТ-сфере. Гораздо труднее бороться с последствиями сбоев, о которых уже кричат пользователи, чем внести в систему исправление, пока ничего критичного не произошло.
Есть тут, конечно, скрытая выгода. Посудите сами: если 1С-ник постоянно тушит пожары, его работа становится хорошо заметна. У пользователей складывается впечатление, что без этого спеца вообще никак не обойтись. Но работать в стрессовом режиме — плохо. Мало того, что 1С-ник быстро выгорит, так еще и пользователи напрасно тратят время, бодаясь с программой. А могли бы основной работой заниматься!
Какие есть источники проблем с 1С и как их предупредить? Давайте разбираться.
1. Главная проблема — это пользователи. 🙂 Не все, конечно. Но есть те, кто не очень хорошо представляет, что делает, и к чему эти действия могут привести. Работал как-то с сотрудником, который постоянно отключал контроль остатков, когда у него не проводились документы. «У меня машина уже загружена товаром, водитель ждет счета-фактуры, а ваших остатков ждать не будет», — отвечал он на мои просьбы так не делать. Это приводило к проблемам в работе других пользователей, а также к сложным шаманским обрядам при закрытии месяца.
Что делать: настраивать ограничение прав. Если типовых возможностей не хватает, программируйте дополнительные ограничения.
2. Доработка 1С неопытным спецом. В такие моменты могут появиться серьезные ошибки, я уже не говорю про не оптимальные доработки. Это может привести к неудобствам, тормозам и даже к искажению учетных данных.
Что делать: тестировать доработки до помещения в прод (рабочая база). Подробнее о программных ошибках писал здесь. Также можно организовать работу начинающего специалиста под руководством опытного. Он будет ставить задачи, наставлять, проверять код. Или делать все вместе. 😄
3. Технические сбои. Про аппаратную часть я не буду говорить — это не наша вотчина. А вот недоступность сторонних сервисов, с которыми взаимодействует 1С (электронная почта, банк, сайт и т.д.), последствия внезапной перезагрузки сервера или закончившееся место на дисках – на это 1С-ник должен отреагировать. Мне приходилось тратить часы и дни на решение проблем, которых можно избежать, если посматривать время от времени в журнал регистрации 1С.
Что делать: мониторить систему (журнал регистрации 1С, свободное место на диске и т.д.). Делюсь своими наработками для автоматизации этого процесса. Берите на вооружение, настраивайте под себя, добавляйте диагностики. Мне автоматизация мониторинга в базах 1С сэкономила много времени и нервов.
Ну и совет бонусом: если после решения каждой проблемы делать что-то, чтобы эта проблема больше не повторялась, через какое-то время жить и работать станет намного легче.
🔥 — если советы полезны
❤️ — если и сами это знаете и применяете
🤔 — если считаете, что предупреждать проблемы не в интересах 1С-ника (ведь так можно и без работы остаться).
#кейсы
Болезнь легче предупредить, чем лечить — слышали такое? Это применимо и к ИТ-сфере. Гораздо труднее бороться с последствиями сбоев, о которых уже кричат пользователи, чем внести в систему исправление, пока ничего критичного не произошло.
Есть тут, конечно, скрытая выгода. Посудите сами: если 1С-ник постоянно тушит пожары, его работа становится хорошо заметна. У пользователей складывается впечатление, что без этого спеца вообще никак не обойтись. Но работать в стрессовом режиме — плохо. Мало того, что 1С-ник быстро выгорит, так еще и пользователи напрасно тратят время, бодаясь с программой. А могли бы основной работой заниматься!
Какие есть источники проблем с 1С и как их предупредить? Давайте разбираться.
1. Главная проблема — это пользователи. 🙂 Не все, конечно. Но есть те, кто не очень хорошо представляет, что делает, и к чему эти действия могут привести. Работал как-то с сотрудником, который постоянно отключал контроль остатков, когда у него не проводились документы. «У меня машина уже загружена товаром, водитель ждет счета-фактуры, а ваших остатков ждать не будет», — отвечал он на мои просьбы так не делать. Это приводило к проблемам в работе других пользователей, а также к сложным шаманским обрядам при закрытии месяца.
Что делать: настраивать ограничение прав. Если типовых возможностей не хватает, программируйте дополнительные ограничения.
2. Доработка 1С неопытным спецом. В такие моменты могут появиться серьезные ошибки, я уже не говорю про не оптимальные доработки. Это может привести к неудобствам, тормозам и даже к искажению учетных данных.
Что делать: тестировать доработки до помещения в прод (рабочая база). Подробнее о программных ошибках писал здесь. Также можно организовать работу начинающего специалиста под руководством опытного. Он будет ставить задачи, наставлять, проверять код. Или делать все вместе. 😄
3. Технические сбои. Про аппаратную часть я не буду говорить — это не наша вотчина. А вот недоступность сторонних сервисов, с которыми взаимодействует 1С (электронная почта, банк, сайт и т.д.), последствия внезапной перезагрузки сервера или закончившееся место на дисках – на это 1С-ник должен отреагировать. Мне приходилось тратить часы и дни на решение проблем, которых можно избежать, если посматривать время от времени в журнал регистрации 1С.
Что делать: мониторить систему (журнал регистрации 1С, свободное место на диске и т.д.). Делюсь своими наработками для автоматизации этого процесса. Берите на вооружение, настраивайте под себя, добавляйте диагностики. Мне автоматизация мониторинга в базах 1С сэкономила много времени и нервов.
Ну и совет бонусом: если после решения каждой проблемы делать что-то, чтобы эта проблема больше не повторялась, через какое-то время жить и работать станет намного легче.
🔥 — если советы полезны
❤️ — если и сами это знаете и применяете
🤔 — если считаете, что предупреждать проблемы не в интересах 1С-ника (ведь так можно и без работы остаться).
#кейсы
🔥32❤5👍3❤🔥2🤔2🥴1
Как (не) потерять данные при настроенном резервном копировании: ликбез для 1С-ника
В айтишном фольклоре есть хорошая поговорка: «Админы делятся на тех, кто не делает резервные копии (бекапы), и тех, кто уже делает». Опытные админы к этому добавляют: «А еще есть те, кто уже проверяют бекапы».
Осознание этих истин рано или поздно приходит и к спецам, сопровождающим базы 1С.
Как-то утром пришло сообщение от главбуха: «Не работает база 1С бухгалтерии. Висит окно запуска уже час, но ничего не происходит». Иду к системному администратору. Он говорит, что ночью был сбой на серверах (скорее всего, из-за этого и возникла проблема с базой 1С), и резонно спрашивает: «Что будем делать?»
Что за вопрос! Тут и думать нечего. Мы ведь не какие-нибудь безответственные дилетанты, у нас резервное копирование настроено! Предлагаю восстановить базу из ночного бекапа.
Сказано — сделано. Но через некоторое время опять звонит главбух и сообщает, что последние документы в базе — двухмесячной давности…
У меня выступил холодный пот. Ведь актуальную рабочую базу мы удалили, когда загрузили в нее бекап. Проверяю: так и есть, последние документы введены два месяца назад.
Спрашиваю сисадмина, как такое могло получиться и почему последняя резервная копия такая старая? Он, конечно, ничего вразумительного не отвечает. Зато следом предлагает вместе бекапы проверить.
Предложение отличное, а главное, очень своевременное, думаю я. И судорожно соображаю, что делать. Ищу другие бекапы (при обновлении конфигурации мы делаем дополнительные резервные копии), прикидываю варианты — как еще можно восстановить потерянные данные. Хотя бы частично, например, переносом документов из другой конфигурации.
Составив какой-никакой план, перехожу к следующему важному этапу — продумываю и репетирую траурную речь: «С тяжелым сердцем сообщаю [...]. Документы потерялись так неожиданно, никто не может подготовиться к такому [...]. Но надо жить и работать дальше, восстанавливать учет и годовую отчетность [...]. Вместе мы со всем справимся».
Набравшись храбрости, звоню главбуху, произношу речь, даю пояснения, возлагаю ответственность на себя. Надо отдать должное, она приняла эту новость достойно, почти неплакала охала.
Перед тем, как начать восстанавливать данные, я вернулся к сисадмину:
— Как же ты, — спрашиваю, — не заметил, что резервные копии не делаются?
— Так они делаются, — отвечает, — я восстанавливал данные из бекапа от вчерашней даты.
— Это что же получается, во вчерашнем бекапе данные двухмесячной давности?
И тут мы с ним вспомнили, что как раз пару месяцев назад скопировали эту базу на другой сервер. А резервное копирование старой базы никто не отключал. И админ просто перепутал бекапы старой и новой базы (для которой, слава богу, резервное копирование тоже было настроено). Базу мы восстановили. Какую же радость и облегчение иногда можно испытать, решивнесуществующую страшную проблему. И при этом не сделав абсолютно ничего полезного. 🙂
Из этой истории я сделал такие выводы:
1⃣ Восстанавливать бекап нужно только в новую базу.
2⃣ Необходимо проверять не только то, есть ли бекап, но и хотя бы иногда смотреть, что лежит в нем и удается ли его развернуть.
3⃣ Если голова не на месте, то никакие бекапы не помогут. 🙂 Когда клиентов, задач и баз становится много, пора заниматься организацией учета не только для клиентов, но и для себя.
Знакома вам потеря данных в 1С?
🔥 — да, было дело, отделались легким испугом.
😱 — сталкивались, даже вспоминать не хочу, чем это все закончилось.
👍 — у нас все четко, таких факапов (тьфу-тьфу-тьфу) не бывало.
Может, хотите что-то добавить из своего опыта?
#истории
В айтишном фольклоре есть хорошая поговорка: «Админы делятся на тех, кто не делает резервные копии (бекапы), и тех, кто уже делает». Опытные админы к этому добавляют: «А еще есть те, кто уже проверяют бекапы».
Осознание этих истин рано или поздно приходит и к спецам, сопровождающим базы 1С.
Как-то утром пришло сообщение от главбуха: «Не работает база 1С бухгалтерии. Висит окно запуска уже час, но ничего не происходит». Иду к системному администратору. Он говорит, что ночью был сбой на серверах (скорее всего, из-за этого и возникла проблема с базой 1С), и резонно спрашивает: «Что будем делать?»
Что за вопрос! Тут и думать нечего. Мы ведь не какие-нибудь безответственные дилетанты, у нас резервное копирование настроено! Предлагаю восстановить базу из ночного бекапа.
Сказано — сделано. Но через некоторое время опять звонит главбух и сообщает, что последние документы в базе — двухмесячной давности…
У меня выступил холодный пот. Ведь актуальную рабочую базу мы удалили, когда загрузили в нее бекап. Проверяю: так и есть, последние документы введены два месяца назад.
Спрашиваю сисадмина, как такое могло получиться и почему последняя резервная копия такая старая? Он, конечно, ничего вразумительного не отвечает. Зато следом предлагает вместе бекапы проверить.
Предложение отличное, а главное, очень своевременное, думаю я. И судорожно соображаю, что делать. Ищу другие бекапы (при обновлении конфигурации мы делаем дополнительные резервные копии), прикидываю варианты — как еще можно восстановить потерянные данные. Хотя бы частично, например, переносом документов из другой конфигурации.
Составив какой-никакой план, перехожу к следующему важному этапу — продумываю и репетирую траурную речь: «С тяжелым сердцем сообщаю [...]. Документы потерялись так неожиданно, никто не может подготовиться к такому [...]. Но надо жить и работать дальше, восстанавливать учет и годовую отчетность [...]. Вместе мы со всем справимся».
Набравшись храбрости, звоню главбуху, произношу речь, даю пояснения, возлагаю ответственность на себя. Надо отдать должное, она приняла эту новость достойно, почти не
Перед тем, как начать восстанавливать данные, я вернулся к сисадмину:
— Как же ты, — спрашиваю, — не заметил, что резервные копии не делаются?
— Так они делаются, — отвечает, — я восстанавливал данные из бекапа от вчерашней даты.
— Это что же получается, во вчерашнем бекапе данные двухмесячной давности?
И тут мы с ним вспомнили, что как раз пару месяцев назад скопировали эту базу на другой сервер. А резервное копирование старой базы никто не отключал. И админ просто перепутал бекапы старой и новой базы (для которой, слава богу, резервное копирование тоже было настроено). Базу мы восстановили. Какую же радость и облегчение иногда можно испытать, решив
Из этой истории я сделал такие выводы:
1⃣ Восстанавливать бекап нужно только в новую базу.
2⃣ Необходимо проверять не только то, есть ли бекап, но и хотя бы иногда смотреть, что лежит в нем и удается ли его развернуть.
3⃣ Если голова не на месте, то никакие бекапы не помогут. 🙂 Когда клиентов, задач и баз становится много, пора заниматься организацией учета не только для клиентов, но и для себя.
Знакома вам потеря данных в 1С?
🔥 — да, было дело, отделались легким испугом.
😱 — сталкивались, даже вспоминать не хочу, чем это все закончилось.
👍 — у нас все четко, таких факапов (тьфу-тьфу-тьфу) не бывало.
Может, хотите что-то добавить из своего опыта?
#истории
🔥39👍18😱7❤2
Как у вас организовано тестирование разработок?
🔥 – относимся к тестированию серьезно – модульные тесты, сценарные тесты и т.д. для нас обычная практика;
👍 – надеемся на опыт разработчиков, проводим ревью кода менее опытных коллег;
🤔 – в мире 1С лучшие тестировщики – это конечные пользователи!
У вас другой вариант? Напишите в комментариях!
#опросы #юмор
🔥 – относимся к тестированию серьезно – модульные тесты, сценарные тесты и т.д. для нас обычная практика;
👍 – надеемся на опыт разработчиков, проводим ревью кода менее опытных коллег;
🤔 – в мире 1С лучшие тестировщики – это конечные пользователи!
У вас другой вариант? Напишите в комментариях!
#опросы #юмор
🤔49👍13🔥9
Автоматизация — не панацея: рассказываю, когда она (не) нужна
Некоторые проблемы лучше не решать, а избегать. (с) Тони Хоар, английский ученый, специалист в области информатики и вычислительной техники.
Считается, что автоматизация учета — это всегда хорошо. Но, на мой взгляд, это не так. Предлагаю несколько вопросов, на которые стоит ответить, прежде чем что-то автоматизировать.
1. Будет ли экономический эффект? Да, это самый очевидный вопрос. Но ответить на него не всегда просто. Если говорить про внедрение какой-то типовой конфигурации 1С, тут сомнений в целесообразности обычно не возникает. Ведь ручной учет с помощью амбарных книг уже почти никто не ведет. Но если речь о разработке нетипового функционала, важно оценить, сколько он будет стоить и принесет ли пользу.
Оценить разработку и внедрение новых механизмов учета не так уж сложно (об этом еще напишу). Тяжелее с расчетом экономического эффекта. Но можно хотя бы примерно прикинуть:
✅ сколько времени вы сэкономите и как это отразится на финансах
✅ можно ли получить дополнительную прибыль
✅ на какую сумму получится сократить затраты.
Если стоимость разработки на порядок выше, чем ожидаемый экономический эффект, то есть смысл задуматься — а оно вам надо? 🙂
2. Сколько будет стоить эксплуатация нововведения? Соблюдается ли, например, баланс между детальностью учета и трудоемкостью его ведения? Тут расскажу историю из жизни.
Одно время работал на небольшом заводе. Руководство поставило задачу — организовать учет материалов так, чтобы рассчитывать точную себестоимость каждого отдельного изделия. Получился большой и сложный проект, который затронул, в частности, кладовщиков. Им торжественно объявили: «Теперь мы работаем по-новому! Если раньше вы просто выдавали 4-метровый металлический уголок мастеру, то теперь должны отразить в системе, сколько сантиметров этого уголка и на какое изделие будет израсходовано. А еще, сколько осталось обрезков и какой они длины».
Двое кладовщиков уволились сразу. Чтобы не убежали остальные, гениальную идею поставили на стоп. Дальше удалось убедить руководство, что пользы от такого учета не так много, а трудозатраты слишком высоки. Реализовали другой проект: точность расчета, впрочем, оказалась достаточной для управленцев.
3. Можно реорганизовать процессы, а не автоматизировать те, что есть? Иногда можно изменить бизнес-процесс так, что автоматизировать его становится гораздо проще. А иногда реорганизация позволит и вовсе отказаться от автоматизации.
Как-то раз ко мне обратилось руководство торговой компании. Несколько раз встречались с директором, обсуждали, как организовать работу отдела доставки и автоматизировать ее в 1С. Собеседник ожидал, что все будет просто: поставил программу, настроил — работает. Но оказалось, что нужен новый сотрудник, обучение. К тому же все это получается не так дешево. В результате на очередной встрече он мне заявляет: «Слушай, не нужно это все, я просто отдам доставку на аутсорс, пусть спецы этим занимаются». Так необходимость автоматизации учета отпала сама собой. 🙂
Я не расстроился. Если уж делать что-то для бизнеса, то действительно полезное. Поделитесь, а что вас мотивирует к работе над задачей больше:
🔥 — польза для компании, облегчение жизни пользователям
👍 — прежде всего, задача должна интересовать меня
🤔 — мотивируют только деньги (зато честно!)
#кейсы
Некоторые проблемы лучше не решать, а избегать. (с) Тони Хоар, английский ученый, специалист в области информатики и вычислительной техники.
Считается, что автоматизация учета — это всегда хорошо. Но, на мой взгляд, это не так. Предлагаю несколько вопросов, на которые стоит ответить, прежде чем что-то автоматизировать.
1. Будет ли экономический эффект? Да, это самый очевидный вопрос. Но ответить на него не всегда просто. Если говорить про внедрение какой-то типовой конфигурации 1С, тут сомнений в целесообразности обычно не возникает. Ведь ручной учет с помощью амбарных книг уже почти никто не ведет. Но если речь о разработке нетипового функционала, важно оценить, сколько он будет стоить и принесет ли пользу.
Оценить разработку и внедрение новых механизмов учета не так уж сложно (об этом еще напишу). Тяжелее с расчетом экономического эффекта. Но можно хотя бы примерно прикинуть:
Если стоимость разработки на порядок выше, чем ожидаемый экономический эффект, то есть смысл задуматься — а оно вам надо? 🙂
2. Сколько будет стоить эксплуатация нововведения? Соблюдается ли, например, баланс между детальностью учета и трудоемкостью его ведения? Тут расскажу историю из жизни.
Одно время работал на небольшом заводе. Руководство поставило задачу — организовать учет материалов так, чтобы рассчитывать точную себестоимость каждого отдельного изделия. Получился большой и сложный проект, который затронул, в частности, кладовщиков. Им торжественно объявили: «Теперь мы работаем по-новому! Если раньше вы просто выдавали 4-метровый металлический уголок мастеру, то теперь должны отразить в системе, сколько сантиметров этого уголка и на какое изделие будет израсходовано. А еще, сколько осталось обрезков и какой они длины».
Двое кладовщиков уволились сразу. Чтобы не убежали остальные, гениальную идею поставили на стоп. Дальше удалось убедить руководство, что пользы от такого учета не так много, а трудозатраты слишком высоки. Реализовали другой проект: точность расчета, впрочем, оказалась достаточной для управленцев.
3. Можно реорганизовать процессы, а не автоматизировать те, что есть? Иногда можно изменить бизнес-процесс так, что автоматизировать его становится гораздо проще. А иногда реорганизация позволит и вовсе отказаться от автоматизации.
Как-то раз ко мне обратилось руководство торговой компании. Несколько раз встречались с директором, обсуждали, как организовать работу отдела доставки и автоматизировать ее в 1С. Собеседник ожидал, что все будет просто: поставил программу, настроил — работает. Но оказалось, что нужен новый сотрудник, обучение. К тому же все это получается не так дешево. В результате на очередной встрече он мне заявляет: «Слушай, не нужно это все, я просто отдам доставку на аутсорс, пусть спецы этим занимаются». Так необходимость автоматизации учета отпала сама собой. 🙂
Я не расстроился. Если уж делать что-то для бизнеса, то действительно полезное. Поделитесь, а что вас мотивирует к работе над задачей больше:
🔥 — польза для компании, облегчение жизни пользователям
👍 — прежде всего, задача должна интересовать меня
🤔 — мотивируют только деньги (зато честно!)
#кейсы
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19👍13🤔8👎1
Как-то раз (я был еще совсем молодым программистом) пришлось проводить собеседования с кандидатами на должность оператора ПК в страховой компании. "Ну ты выпиши сюда тех, кто тебе понравился, и чем он тебе понравился", поставил задачу начальник отдела, вручая мне чистый листок и ручку. 🙂
Были у вас ситуации, когда на работе делали не совсем то, что вам полагается по должности?
#юмор
Были у вас ситуации, когда на работе делали не совсем то, что вам полагается по должности?
#юмор
😁11🔥10❤2
Дедлайн — вчера: как правильно оценить трудоемкость задачи
Каждый 1С-ник сталкивался с оценкой задачи. И, почти уверен, многим доводилось страшно ошибаться не в свою пользу. А потом либо думать, как же согласовать дополнительные сроки, либо изо всех сил стараться уложиться в озвученный вариант (нередко в ущерб качеству).
Что делать? Есть различные более-менее формальные модели (например, COCOMO II), в которых эксперт должен дать оценку количества строк кода в проекте. Исходя из этого высчитывается критерий трудоемкости.
Но, как говорил Билл Гейтс, «измерять трудоемкость программирования подсчетом строк кода — это все равно, что оценивать постройку самолета по его весу». Думаю, для 1С-проектов это верно втройне. Я ни разу не сталкивался с тем, чтобы работу 1С-ника анализировали с помощью формальных методик. Этим всегда занимается эксперт.
Проблемы чаще всего возникают, когда оценщик — это неопытный специалист:
а) Ему сложно декомпозировать проект на небольшие части.
б) У него не хватает опыта, чтобы прикинуть трудоемкость работ. Особенно если еще не сталкивался с похожими задачами.
в) Он оценивает, например, только разработку, и забывает про неочевидные дополнительные работы.
Есть шуточная формула для получения реальной оценки задачи (Треал) по оценке программиста (Тпрогр):
Треал = Тпрогр ✕ π ✕ e
Формула рабочая, советую 🙂. Но если вам хочется лучшего обоснования, тогда используйте мои наработки (подходит для небольших задач). Они мало помогут с пунктами (а) и (б) из списка выше, но позволят не забыть о важном пункте (в).
Анализ сроков — отдельная тема. О ней в следующий раз.
Ошибаетесь в оценке?
🔥 — часто, но только в свою пользу!
😱 — постоянно недооцениваю реальные трудозатраты и сроки, мучаюсь из-за этого.
👍 — оценкой не занимаюсь, но возьму на вооружение твои наработки, и ух!.. 🙂
#кейсы
Каждый 1С-ник сталкивался с оценкой задачи. И, почти уверен, многим доводилось страшно ошибаться не в свою пользу. А потом либо думать, как же согласовать дополнительные сроки, либо изо всех сил стараться уложиться в озвученный вариант (нередко в ущерб качеству).
Что делать? Есть различные более-менее формальные модели (например, COCOMO II), в которых эксперт должен дать оценку количества строк кода в проекте. Исходя из этого высчитывается критерий трудоемкости.
Но, как говорил Билл Гейтс, «измерять трудоемкость программирования подсчетом строк кода — это все равно, что оценивать постройку самолета по его весу». Думаю, для 1С-проектов это верно втройне. Я ни разу не сталкивался с тем, чтобы работу 1С-ника анализировали с помощью формальных методик. Этим всегда занимается эксперт.
Проблемы чаще всего возникают, когда оценщик — это неопытный специалист:
а) Ему сложно декомпозировать проект на небольшие части.
б) У него не хватает опыта, чтобы прикинуть трудоемкость работ. Особенно если еще не сталкивался с похожими задачами.
в) Он оценивает, например, только разработку, и забывает про неочевидные дополнительные работы.
Есть шуточная формула для получения реальной оценки задачи (Треал) по оценке программиста (Тпрогр):
Треал = Тпрогр ✕ π ✕ e
Формула рабочая, советую 🙂. Но если вам хочется лучшего обоснования, тогда используйте мои наработки (подходит для небольших задач). Они мало помогут с пунктами (а) и (б) из списка выше, но позволят не забыть о важном пункте (в).
Анализ сроков — отдельная тема. О ней в следующий раз.
Ошибаетесь в оценке?
🔥 — часто, но только в свою пользу!
😱 — постоянно недооцениваю реальные трудозатраты и сроки, мучаюсь из-за этого.
👍 — оценкой не занимаюсь, но возьму на вооружение твои наработки, и ух!.. 🙂
#кейсы
😱28👍18🔥5👏2
Дедлайн — вчера (часть 2): сделаю за один час через два дня
Еще не забыли, о чем был прошлый пост? 🙂 Мы говорили, как оценивать трудоемкость задачи. А что слышно по срокам?
Предположим, вы оценили, что сделаете работу за 16 часов. Но это вовсе не значит, что через два дня клиент получит то, чего так ждет.
Почему нет?
– Спец, который будет работать над задачей, сейчас может быть занят другим проектом. А приступить к новому получится только через несколько дней.
– Спец может взять новую задачу параллельно с другими, тогда у него получится уделять ей только пару часов в день.
– Возможно, часть работы будет выполнять стажер, у которого пока уходит больше времени, чем у его старшего коллеги. К тому же его решение должен будет проверить опытный спец. А он не всегда свободен, не приступит к проверке мгновенно.
– Есть вероятность, что во время работы над новой задачей появятся другие, более приоритетные, на которые придется срочно переключиться. Например, это может быть устранение косяков по каким-то уже сданным работам, которые клиент активно тестирует.
– Имейте в виду: программировать 8 часов в день нереально. По крайней мере я не видел таких монстров, которые могли бы эффективно разрабатывать весь рабочий день. Чаще всего слышал (и мой опыт это подтверждает), что у программиста максимум 4-5 эффективных часов в день.
– В процессе работы над задачей иногда возникают вопросы, требующие уточнения у клиента. Если тот не может оперативно ответить, это тоже увеличивает срок выполнения работ.
При оценке сроков задаемся вопросами:
1. Когда каждый участник проекта сможет приступить к работе?
2. Сколько часов в день они смогут уделять проекту?
3. Из-за чего могут возникнуть задержки?
Я как-то писал, что лучше озвучить дедлайн с запасом и сделать чуть раньше, чем проштрафиться. Если срок в 2-3 раза превышает трудоемкость, обычно у заказчика вопросов не возникает.
Ставьте 🔥, если узнали что-то новое для себя. Ну или 🤓, если давно все это применяете.
#кейсы
Еще не забыли, о чем был прошлый пост? 🙂 Мы говорили, как оценивать трудоемкость задачи. А что слышно по срокам?
Предположим, вы оценили, что сделаете работу за 16 часов. Но это вовсе не значит, что через два дня клиент получит то, чего так ждет.
Почему нет?
– Спец, который будет работать над задачей, сейчас может быть занят другим проектом. А приступить к новому получится только через несколько дней.
– Спец может взять новую задачу параллельно с другими, тогда у него получится уделять ей только пару часов в день.
– Возможно, часть работы будет выполнять стажер, у которого пока уходит больше времени, чем у его старшего коллеги. К тому же его решение должен будет проверить опытный спец. А он не всегда свободен, не приступит к проверке мгновенно.
– Есть вероятность, что во время работы над новой задачей появятся другие, более приоритетные, на которые придется срочно переключиться. Например, это может быть устранение косяков по каким-то уже сданным работам, которые клиент активно тестирует.
– Имейте в виду: программировать 8 часов в день нереально. По крайней мере я не видел таких монстров, которые могли бы эффективно разрабатывать весь рабочий день. Чаще всего слышал (и мой опыт это подтверждает), что у программиста максимум 4-5 эффективных часов в день.
– В процессе работы над задачей иногда возникают вопросы, требующие уточнения у клиента. Если тот не может оперативно ответить, это тоже увеличивает срок выполнения работ.
При оценке сроков задаемся вопросами:
1. Когда каждый участник проекта сможет приступить к работе?
2. Сколько часов в день они смогут уделять проекту?
3. Из-за чего могут возникнуть задержки?
Я как-то писал, что лучше озвучить дедлайн с запасом и сделать чуть раньше, чем проштрафиться. Если срок в 2-3 раза превышает трудоемкость, обычно у заказчика вопросов не возникает.
Ставьте 🔥, если узнали что-то новое для себя. Ну или 🤓, если давно все это применяете.
#кейсы
🔥14🤓7❤5👍3🥰1
Дедлайн — вчера (часть 3): как оценивать большие проекты
В предыдущих постах (раз и два) рассказывал об оценке задач, которые можно назвать небольшими. Но для крупных проектов это все не подходит. А что тогда?
Как-то меня попросили оценить проект внедрения «Зарплата и управление персоналом» (ЗУП) в холдинге. До этого в настолько крупных задачах я участвовал несколько раз — в роли программиста/консультанта/тимлида. Но полностью все спланировать и оценить еще не приходилось. Это вообще-то работа руководителя проекта, но в тот момент свободных рук не было.
В общем, подошел я к этому делу ответственно. Сразу собрал документы с оценками похожих и не очень проектов. Рассказываю, чем они отличались от небольших задач:
1. План укрупненный, проект разбивается на этапы. Для каждого пункта описаны результаты и критерии приемки.
2. Для каждой задачи указывается количество специалистов по ролям.
3. Оценка чаще всего происходит не в часах, а в человеко-днях.
4. Составляется план-график проекта. Оценка включает не только трудоемкость, но и сроки.
5. Подробно описываются допущения и ограничения. Чтобы заказчик понимал, что будем делать мы, а что должен сделать он, какие факторы могут усложнить проект и сдвинуть сроки.
Более того, составил список проблемных ситуаций, которые возникали у меня и коллег при внедрениях ЗУП. Это помогло скорректировать оценки некоторых этапов(умножить их на π и на e, шучу 🙂) , описать допущения и ограничения.
А еще побеседовал с ответственными со стороны заказчика. Обсудили этапы, сроки, сформировали и согласовали итоговый документ. Вот, что получилось (примерно).
При оценке трудоемкости и сроков масштабного проекта вряд ли можно ошибиться в большую сторону. Работает закон Паркинсона: работа будет заполнять все время, на нее отведенное. А чем скромнее бюджет, тем чаще у исполнителя будут возникать причины, почему что-то он сделать не может и не будет.
Документы я отдал руководителю, и вернулся к обычным программистским задачам. А через некоторое время выяснилось, что клиент решился с нами работать. Тут же объявили: раз оценку дал я, то мне за нее и отвечать. Иными словами, пришлось руководить проектом.
Первая мысль — меня подставили 🙂. Хотя рад, что согласился, интересный был опыт. Но это уже другая история, расскажу в следующий раз.
Заметили, что оценка стоимости основывается на времени работы спецов? Традиционный опрос. За какие часы вам комфортнее работать:
👍 — за фактические: сколько отработал, за столько и должен получить. Все по-честному.
🔥 — за плановые: какую сумму с заказчиком согласовали, за такую и работаю. Сделал быстрее — молодец. Промахнулся с оценкой — в следующий раз буду умнее.
🤔 — почасовка не для меня, выдавайте мне оклад вовремя!
#кейсы
В предыдущих постах (раз и два) рассказывал об оценке задач, которые можно назвать небольшими. Но для крупных проектов это все не подходит. А что тогда?
Как-то меня попросили оценить проект внедрения «Зарплата и управление персоналом» (ЗУП) в холдинге. До этого в настолько крупных задачах я участвовал несколько раз — в роли программиста/консультанта/тимлида. Но полностью все спланировать и оценить еще не приходилось. Это вообще-то работа руководителя проекта, но в тот момент свободных рук не было.
В общем, подошел я к этому делу ответственно. Сразу собрал документы с оценками похожих и не очень проектов. Рассказываю, чем они отличались от небольших задач:
1. План укрупненный, проект разбивается на этапы. Для каждого пункта описаны результаты и критерии приемки.
2. Для каждой задачи указывается количество специалистов по ролям.
3. Оценка чаще всего происходит не в часах, а в человеко-днях.
4. Составляется план-график проекта. Оценка включает не только трудоемкость, но и сроки.
5. Подробно описываются допущения и ограничения. Чтобы заказчик понимал, что будем делать мы, а что должен сделать он, какие факторы могут усложнить проект и сдвинуть сроки.
Более того, составил список проблемных ситуаций, которые возникали у меня и коллег при внедрениях ЗУП. Это помогло скорректировать оценки некоторых этапов
А еще побеседовал с ответственными со стороны заказчика. Обсудили этапы, сроки, сформировали и согласовали итоговый документ. Вот, что получилось (примерно).
При оценке трудоемкости и сроков масштабного проекта вряд ли можно ошибиться в большую сторону. Работает закон Паркинсона: работа будет заполнять все время, на нее отведенное. А чем скромнее бюджет, тем чаще у исполнителя будут возникать причины, почему что-то он сделать не может и не будет.
Документы я отдал руководителю, и вернулся к обычным программистским задачам. А через некоторое время выяснилось, что клиент решился с нами работать. Тут же объявили: раз оценку дал я, то мне за нее и отвечать. Иными словами, пришлось руководить проектом.
Первая мысль — меня подставили 🙂. Хотя рад, что согласился, интересный был опыт. Но это уже другая история, расскажу в следующий раз.
Заметили, что оценка стоимости основывается на времени работы спецов? Традиционный опрос. За какие часы вам комфортнее работать:
👍 — за фактические: сколько отработал, за столько и должен получить. Все по-честному.
🔥 — за плановые: какую сумму с заказчиком согласовали, за такую и работаю. Сделал быстрее — молодец. Промахнулся с оценкой — в следующий раз буду умнее.
🤔 — почасовка не для меня, выдавайте мне оклад вовремя!
#кейсы
👍14🤔14🔥11❤1
Дайджест публикаций за 4 месяца
Оглянулся и понял, что насобирал приличный портфель постов. Хочется напомнить и вам, вдруг что-то пропустили. Для удобства разделил на блоки. Спасибо, что читаете и активничаете, для любого автора это лучший стимул продолжать писать.
Истории из жизни программиста-консультанта. Поучительные и не очень:
🔹 Какой должна быть зарплата, чтобы цифры не влезали в расчетный лист. Увидели, как мелкая доработка может оказаться серьезной проблемой. И поняли, что 1С-ник — это иногда немного дизайнер.
🔹 Как ошибка в интерфейсе может испортить даже очень хорошую программу. Узнали, что Лев Толстой говорил о пользовательском интерфейсе (ну почти).
🔹 Почему код, который работает правильно, может быть плохим. Попытались выяснить, кому нужен «хороший код», ведь достаточно просто рабочего. Или нет? И продолжили раскрывать эту тему более детально.
🔹 Всегда ли четкая постановка задачи заказчиком – это хорошо. Сравнили желания заказчика с его потребностями.
🔹 Как (не) потерять данные при настроенном резервном копировании. История о загадочной пропаже двух месяцев учетной информации. Опрос показал, что с потерей данных в 1С многие знакомы не понаслышке.
🔹 Должен ли 1С-ник учить пользователя? Поняли, что путаница в голове у пользователя — беда для 1С-ника. Многие читатели согласились, что учить пользователей все-таки надо.
Советы, кейсы, наработки:
🔸 Что сделать 1С-нику, чтобы заказчик остался доволен. Поговорили о soft-skills. Заметили, что у программистов с ними не всегда хорошо.
🔸 5 недостатков кода, из-за которых его сопровождение превращается в ад. Выясняли как надо и как НЕ надо писать программы. И что делать, чтобы код становился лучше.
🔸 Серия «Дедлайн — вчера». Посмотрели, как оценивать трудоемкость, сроки небольших задач и больших проектов (с примерами). Опрос показал, что многие недооценивают реальные трудозатраты и потом из-за этого мучаются.
🔸 Как предупреждать проблемы с 1С. Рассмотрели, что именно нужно делать, чтобы в жизни спеца и пользователя 1С было меньше стрессов и потрясений.
🔸 Как сообщить 1С-нику об ошибке, чтобы он сразу все понял. Самое простое, сказать: «Ваша программа не работает!» Но есть вариант получше. И он тоже простой.
🔸 Как сделать отличную разработку, и при этом страшно накосячить. Поговорили об ошибках и тестировании программ. Выяснили, почему исполнителю полезно чаще общаться с заказчиком.
🔸 А нужна ли вам автоматизация? Рассмотрели, о чем стоит задуматься перед запуском нового 1С-проекта.
🔸 Почему увольняются сотрудники. Разобрали реальную задачу и ее решение. Увидели, что важно хорошо подумать, прежде чем звать программиста. И тут же проверили интуицию читателей.
🔸 1С или Excel? Читатели считают, что круче 1С. Но я все же предложил свои наработки, позволяющие использовать программы вместе. И рассказал, когда и почему это бывает удобно.
Опросы о наболевшем:
🔻 1С-ник — это тру-программист? Многие считают, что «тру». Высказал мнение о том, откуда вообще возникает такой вопрос.
🔻 Как у вас организовано тестирование разработок? У большинства — пользователями. 🙂 Как ни грустно, но для сферы 1С это норма.
А для тех, кто не особо в теме, но очень хочет разобраться, — мое мнение о причинах популярности 1С.
Что думаете, нужны дайджесты в канале? Помогите определиться:
👍 — да, это как удобная навигация.
🤔 — нет, зачем лишний пост, в котором ничего нового.
🤓 — не знаю, пусть авторы каналов сами этими вопросами задаются.
#дайджесты
Оглянулся и понял, что насобирал приличный портфель постов. Хочется напомнить и вам, вдруг что-то пропустили. Для удобства разделил на блоки. Спасибо, что читаете и активничаете, для любого автора это лучший стимул продолжать писать.
Истории из жизни программиста-консультанта. Поучительные и не очень:
🔹 Какой должна быть зарплата, чтобы цифры не влезали в расчетный лист. Увидели, как мелкая доработка может оказаться серьезной проблемой. И поняли, что 1С-ник — это иногда немного дизайнер.
🔹 Как ошибка в интерфейсе может испортить даже очень хорошую программу. Узнали, что Лев Толстой говорил о пользовательском интерфейсе (ну почти).
🔹 Почему код, который работает правильно, может быть плохим. Попытались выяснить, кому нужен «хороший код», ведь достаточно просто рабочего. Или нет? И продолжили раскрывать эту тему более детально.
🔹 Всегда ли четкая постановка задачи заказчиком – это хорошо. Сравнили желания заказчика с его потребностями.
🔹 Как (не) потерять данные при настроенном резервном копировании. История о загадочной пропаже двух месяцев учетной информации. Опрос показал, что с потерей данных в 1С многие знакомы не понаслышке.
🔹 Должен ли 1С-ник учить пользователя? Поняли, что путаница в голове у пользователя — беда для 1С-ника. Многие читатели согласились, что учить пользователей все-таки надо.
Советы, кейсы, наработки:
🔸 Что сделать 1С-нику, чтобы заказчик остался доволен. Поговорили о soft-skills. Заметили, что у программистов с ними не всегда хорошо.
🔸 5 недостатков кода, из-за которых его сопровождение превращается в ад. Выясняли как надо и как НЕ надо писать программы. И что делать, чтобы код становился лучше.
🔸 Серия «Дедлайн — вчера». Посмотрели, как оценивать трудоемкость, сроки небольших задач и больших проектов (с примерами). Опрос показал, что многие недооценивают реальные трудозатраты и потом из-за этого мучаются.
🔸 Как предупреждать проблемы с 1С. Рассмотрели, что именно нужно делать, чтобы в жизни спеца и пользователя 1С было меньше стрессов и потрясений.
🔸 Как сообщить 1С-нику об ошибке, чтобы он сразу все понял. Самое простое, сказать: «Ваша программа не работает!» Но есть вариант получше. И он тоже простой.
🔸 Как сделать отличную разработку, и при этом страшно накосячить. Поговорили об ошибках и тестировании программ. Выяснили, почему исполнителю полезно чаще общаться с заказчиком.
🔸 А нужна ли вам автоматизация? Рассмотрели, о чем стоит задуматься перед запуском нового 1С-проекта.
🔸 Почему увольняются сотрудники. Разобрали реальную задачу и ее решение. Увидели, что важно хорошо подумать, прежде чем звать программиста. И тут же проверили интуицию читателей.
🔸 1С или Excel? Читатели считают, что круче 1С. Но я все же предложил свои наработки, позволяющие использовать программы вместе. И рассказал, когда и почему это бывает удобно.
Опросы о наболевшем:
🔻 1С-ник — это тру-программист? Многие считают, что «тру». Высказал мнение о том, откуда вообще возникает такой вопрос.
🔻 Как у вас организовано тестирование разработок? У большинства — пользователями. 🙂 Как ни грустно, но для сферы 1С это норма.
А для тех, кто не особо в теме, но очень хочет разобраться, — мое мнение о причинах популярности 1С.
Что думаете, нужны дайджесты в канале? Помогите определиться:
👍 — да, это как удобная навигация.
🤔 — нет, зачем лишний пост, в котором ничего нового.
🤓 — не знаю, пусть авторы каналов сами этими вопросами задаются.
#дайджесты
👍27🤓2❤1🔥1🤔1🥱1
Как стать программистом. И надо ли оно вам
В последнее время все чаще вижу, что многие хотят войти в айти. В частности, попробовать себя в сфере 1С. С чего я это взял? Ну, например:
– рассказывают о диком количестве откликов на вакансии начинающих спецов
– реклама курсов Skillbox не лезет разве что из утюга
– в телеграм-каналах тема входа в IT и зарплат вызывает бурные обсуждения.
Приятно, что твоя сфера стала популярна. Но насколько реально в нее попасть? Поделюсь своим мнением.
Успех в освоении программирования практически гарантирован в двух случаях:
1. Вам это нравится настолько, что вы готовы отдавать много свободного времени на написание программ. Даже несмотря на то, что свободного времени вообще-то нет. И да, не думать о золотых горах, которые обещают через пару месяцев обучения почти на любых курсах. А просто так, для удовольствия.
2. У вас есть хороший наставник, который направляет, мотивирует и поддерживает. Особенно когда после общения с заказчиком вы прикидываете — хватает ли денег на веревку и мыло или все же придется сделать задачу, чтобы еще поднакопить. 🙂
Я не говорю, что в других случаях ничего не выйдет. Нет, ищите да обрящете. Суть в том, что первое — это конструктивная внутренняя мотивация, а второе — конструктивная внешняя. С тем или другим вам будет гораздо проще преодолевать трудности. А без них никак, в этом даже не сомневайтесь.
Освоение программирования — это долгий путь. Я бы даже сказал, путь длиною в жизнь. Не выйдет поучиться годик-другой и дальше спокойно работать. Профессия подразумевает, что часто придется разбираться с чем-то новым. Хоть бы даже код чужой (и свой) постоянно изучать.
Давайте выясним, интересна ли тема входа в профессию программиста, стоит ли ее развивать здесь:
👍 — валяй, может даже в обсуждении поучаствую.
🤔 — не надо, хватает этого в других каналах.
🤓 — ты автор, ты и думай. А мы почитаем. Может быть.
#мнение_о_важном
В последнее время все чаще вижу, что многие хотят войти в айти. В частности, попробовать себя в сфере 1С. С чего я это взял? Ну, например:
– рассказывают о диком количестве откликов на вакансии начинающих спецов
– реклама курсов Skillbox не лезет разве что из утюга
– в телеграм-каналах тема входа в IT и зарплат вызывает бурные обсуждения.
Приятно, что твоя сфера стала популярна. Но насколько реально в нее попасть? Поделюсь своим мнением.
Успех в освоении программирования практически гарантирован в двух случаях:
1. Вам это нравится настолько, что вы готовы отдавать много свободного времени на написание программ. Даже несмотря на то, что свободного времени вообще-то нет. И да, не думать о золотых горах, которые обещают через пару месяцев обучения почти на любых курсах. А просто так, для удовольствия.
2. У вас есть хороший наставник, который направляет, мотивирует и поддерживает. Особенно когда после общения с заказчиком вы прикидываете — хватает ли денег на веревку и мыло или все же придется сделать задачу, чтобы еще поднакопить. 🙂
Я не говорю, что в других случаях ничего не выйдет. Нет, ищите да обрящете. Суть в том, что первое — это конструктивная внутренняя мотивация, а второе — конструктивная внешняя. С тем или другим вам будет гораздо проще преодолевать трудности. А без них никак, в этом даже не сомневайтесь.
Освоение программирования — это долгий путь. Я бы даже сказал, путь длиною в жизнь. Не выйдет поучиться годик-другой и дальше спокойно работать. Профессия подразумевает, что часто придется разбираться с чем-то новым. Хоть бы даже код чужой (и свой) постоянно изучать.
Давайте выясним, интересна ли тема входа в профессию программиста, стоит ли ее развивать здесь:
👍 — валяй, может даже в обсуждении поучаствую.
🤔 — не надо, хватает этого в других каналах.
🤓 — ты автор, ты и думай. А мы почитаем. Может быть.
#мнение_о_важном
👍58🤓16❤3🤔3🔥1
Автор канала, 1981 г.
Как стать программистом. Немного обо мне
Чтобы стать хорошим программистом, начинать пить надо с самых ранних лет. Я, конечно, шучу (но это не точно). Просто у меня сегодня день рождения, мне 42! В этом посте решил немного рассказать о себе — в том числе о том, как я стал 1С-ником.
Несколько фактов из детства:
— Родился и вырос на острове посреди моря. Пальмы? Кокосы? Нет, море — Карское, а остров называется Диксон.
— Родители работали в гражданской авиации. В день моего рождения вертолет пролетал над роддомом, и расстрелял весь комплект сигнальных ракет. Многие испугались, уж не началась ли война.
— Компьютерами увлекался с детства. Вот забавная история из того периода. Первая книжка, которую зачитал до дыр, еще не имея компьютера — «Бейсик – это просто»
— Мечтаю научить компьютер программировать. Чтобы было как в известной песне: «Вкалывают роботы, счастлив человек». 🙂
А теперь факты из трудовой биографии:
— Работаю и живу в Ижевске.
— Закончил местный вуз, защитил диссертацию по компьютерной графике.
— Начинал работу админом в небольших организациях. В то время IT-шников не разделяли по специализациям. Так что был «компьютерщиком» – пока прокладывал сеть, осваивал и внедрял бухгалтерию и зарплату 1С 7.7.
— В 2006 году начал работать в 1С-ном ресурсном центре, где меня сдавали в аренду как на большие проекты, так и на мелкие задачи. Здесь произошел самый значительный профессиональный рост — пришлось осваивать большое количество конфигураций, работать быстро, самостоятельно и в разных командах.
— С 2012 года трудился как субподрядчик у франчей 1С, но от своего юрлица. Работа на проектах у франчей интересная, но довольно напряженная. Начал задумываться, как бы работать спокойнее, не теряя в доходе.
— Сейчас с несколькими помощниками сопровождаем своих клиентов. С франчами работаем редко.
— За все время воспитал порядка десяти 1С-ников и много пользователей.
Расскажите в комментариях как вы пришли в 1С? Поздравления принимаются там же 😌.
#истории
Как стать программистом. Немного обо мне
Чтобы стать хорошим программистом, начинать пить надо с самых ранних лет. Я, конечно, шучу (но это не точно). Просто у меня сегодня день рождения, мне 42! В этом посте решил немного рассказать о себе — в том числе о том, как я стал 1С-ником.
Несколько фактов из детства:
— Родился и вырос на острове посреди моря. Пальмы? Кокосы? Нет, море — Карское, а остров называется Диксон.
— Родители работали в гражданской авиации. В день моего рождения вертолет пролетал над роддомом, и расстрелял весь комплект сигнальных ракет. Многие испугались, уж не началась ли война.
— Компьютерами увлекался с детства. Вот забавная история из того периода. Первая книжка, которую зачитал до дыр, еще не имея компьютера — «Бейсик – это просто»
— Мечтаю научить компьютер программировать. Чтобы было как в известной песне: «Вкалывают роботы, счастлив человек». 🙂
А теперь факты из трудовой биографии:
— Работаю и живу в Ижевске.
— Закончил местный вуз, защитил диссертацию по компьютерной графике.
— Начинал работу админом в небольших организациях. В то время IT-шников не разделяли по специализациям. Так что был «компьютерщиком» – пока прокладывал сеть, осваивал и внедрял бухгалтерию и зарплату 1С 7.7.
— В 2006 году начал работать в 1С-ном ресурсном центре, где меня сдавали в аренду как на большие проекты, так и на мелкие задачи. Здесь произошел самый значительный профессиональный рост — пришлось осваивать большое количество конфигураций, работать быстро, самостоятельно и в разных командах.
— С 2012 года трудился как субподрядчик у франчей 1С, но от своего юрлица. Работа на проектах у франчей интересная, но довольно напряженная. Начал задумываться, как бы работать спокойнее, не теряя в доходе.
— Сейчас с несколькими помощниками сопровождаем своих клиентов. С франчами работаем редко.
— За все время воспитал порядка десяти 1С-ников и много пользователей.
Расскажите в комментариях как вы пришли в 1С? Поздравления принимаются там же 😌.
#истории
🎉36👍17🔥9❤3
А оно мне надо? Кое-что о программировании и качествах спецов
Программист должен обладать способностью первоклассного математика к абстракции и логическому мышлению в сочетании с эдисоновским талантом сооружать все, что угодно, из нуля и единиц. Он должен сочетать аккуратность бухгалтера с проницательностью разведчика, фантазию автора детективных романов — с трезвой практичностью экономиста. А кроме того, программист должен иметь вкус к коллективной работе, понимать интересы пользователя и многое другое… (с) Андрей Ершов, академик АН СССР, один из пионеров теоретического и системного программирования
О как! После прочтения невольно задумываешься — а может, ну его... Хотя постойте. На мой взгляд, чтобы успешно программировать, достаточно всего двух качеств — усидчивости и терпеливости. Почему? Давайте посмотрим, чем занимается такой спец.
1️⃣ Изучает ТЗ. Читать придется основательно, при этом задавать уточняющие вопросы и что-то додумывать самостоятельно. Часто нужно переводить с языка пользователя или аналитика на технический 1С-ный, оценивать трудоемкость, сроки. Это уже большая работа, а программировать еще даже не начали.
2️⃣ Пишет и отлаживает код. Обычно это самое интересное. Но ровно до того момента, когда выясняется: твой код не работает, а ты не понимаешь почему. Тогда приходится читать документацию, искать обсуждение похожих проблем в интернете. В конце концов — доставать шаманский бубен. 🙃 Программирование в этот момент становится совсем не таким простым и интересным, каким казалось в уроках курса «разработчик 1С за две недели».
3️⃣ Ищет и исправляет ошибки, которыесоздал обнаружил пользователь. И не важно, что функционал, в котором возникла проблема, давно сдан и забыт. Да, придется вспоминать и разбираться. Ошибка может крыться в коде, а может и во введенных (или не введенных) пользователем данных. А вдруг это и не ошибка вовсе? Тогда придется доказать, обосновать, а иногда чему-то научить пользователя (желательно без обвинений и мата 🙂) . Ничего особенно захватывающего в этой работе нет, зато сил требуется много.
4️⃣ Разбирает и дорабатывает чужой код. Это, на мой взгляд, самая тяжелая работа. Особенно если копаться приходится в легаси-коде — старом, недокументированном, непонятно кем разработанным, к тому же в несопровождаемом стиле. Забавно, но иногда оказывается, что этот «чужой» легаси-код на самом деле твой собственный!
Без усидчивости и терпения заниматься всем очень тяжело. Эти качества нужно воспитывать в себе в первую очередь. А все остальное приходит с опытом. Согласны? Если у вас другое мнение, жду в комментариях.
🔥 — да, без усидчивости никак (и не только программисту).
🤔 — нет, усидчивость не про 1С-ника. Посмотрите какой ад творится на проектах: у усидчивых и терпеливых такого не бывает!
😱 — прочитал и понял, что не хочу быть программистом!
#мнение_о_важном
О как! После прочтения невольно задумываешься — а может, ну его... Хотя постойте. На мой взгляд, чтобы успешно программировать, достаточно всего двух качеств — усидчивости и терпеливости. Почему? Давайте посмотрим, чем занимается такой спец.
1️⃣ Изучает ТЗ. Читать придется основательно, при этом задавать уточняющие вопросы и что-то додумывать самостоятельно. Часто нужно переводить с языка пользователя или аналитика на технический 1С-ный, оценивать трудоемкость, сроки. Это уже большая работа, а программировать еще даже не начали.
2️⃣ Пишет и отлаживает код. Обычно это самое интересное. Но ровно до того момента, когда выясняется: твой код не работает, а ты не понимаешь почему. Тогда приходится читать документацию, искать обсуждение похожих проблем в интернете. В конце концов — доставать шаманский бубен. 🙃 Программирование в этот момент становится совсем не таким простым и интересным, каким казалось в уроках курса «разработчик 1С за две недели».
3️⃣ Ищет и исправляет ошибки, которые
4️⃣ Разбирает и дорабатывает чужой код. Это, на мой взгляд, самая тяжелая работа. Особенно если копаться приходится в легаси-коде — старом, недокументированном, непонятно кем разработанным, к тому же в несопровождаемом стиле. Забавно, но иногда оказывается, что этот «чужой» легаси-код на самом деле твой собственный!
Без усидчивости и терпения заниматься всем очень тяжело. Эти качества нужно воспитывать в себе в первую очередь. А все остальное приходит с опытом. Согласны? Если у вас другое мнение, жду в комментариях.
🔥 — да, без усидчивости никак (и не только программисту).
🤔 — нет, усидчивость не про 1С-ника. Посмотрите какой ад творится на проектах: у усидчивых и терпеливых такого не бывает!
😱 — прочитал и понял, что не хочу быть программистом!
#мнение_о_важном
🔥46😱9❤3👍2🤔2👎1
Чек-лист самопроверки для начинающего программиста
В прошлом посте мы говорили об усидчивости и терпеливости 1С-ников. Многие согласились, что без этих качеств никак. А можно ли освоить программирование, если усидчивость — не твоя сильная сторона?
Когда-то у меня был подопечный (назовем его Кирилл), которого я с абсолютного нуля учил программировать в 1С. Парень толковый, быстро освоил основы. Я начал давать ему первые реальные задачи и удивлялся скорости, с которой он их решал. Я еще пояснения к заданию договорить не успел, а от Кирилла уже слышал: «Владимир, у меня все готово». Только вот скоро выяснилось: все, что он делает, — работает неправильно или не работает вовсе. 🙂
Почему так получалось?
— ТЗ Кирилл читал по диагонали, и сразу кидался в бой (писать код). Вопросов у него не было, а если и возникали, то ответы он тут же придумывал сам.
— Он был абсолютно уверен, что результат работы программиста — это код, а не работающее решение.
— Пересмотр своего кода (я уже не говорю об изучении чужого) казался Кириллу совершенно пустой тратой времени.
Признаюсь, меня такой подход очень расстраивал. Иногда казалось, что хорошего программиста из Кирилла не выйдет, я зря трачу время. Но что интересно — он без возражений все переписывал, энтузиазм не пропадал. А это, я считаю, главный признак того, что все получится. Нужны просто четкие требования к результату и немного времени.
Я перестал проверять его решения после каждого «у меня все готово». Вместо этого последовательно задавал следующие вопросы:
🔻 Задание прочитал внимательно?
🔻 И тебе прям все-все ясно?
🔻 А решение сделал по всему заданию, ничего не пропустил?
🔻 Свой код перечитал?
🔻 Он точно соответствует заданию?
🔻 Оформил код правильно, красиво, по стандартам/регламентам?
🔻 А запускал его?
🔻 И как, работает? Проверил?
🔻 А работает как предполагается в задании?
🔻 Если неправильные данные ввести, не валится?
Каждый вопрос надо было проработать и утвердительно на него ответить. Качество решения уже получалось таким, что постановщик задачи при дальнейшей проверке хотя бы не ругался матом. 🙂
Опытному спецу эти вопросы могут показаться смешными. Но я вас уверяю, для некоторых начинающих программистов не очевидна даже необходимость запустить программу, чтобы все перепроверить...
Кирилл, кстати, сейчас работает в известной торговой компании программистом 1С. Говорил же, все получится!
Как относитесь к самостоятельной проверке результата работы?
👍 — обязательно перепроверяю.
🔥 — сразу делаю все правильно.
🤔 — чукча не читатель, чукча писатель, а проверкой пусть занимается тот, кто за это деньги получает.
#истории #кейсы
В прошлом посте мы говорили об усидчивости и терпеливости 1С-ников. Многие согласились, что без этих качеств никак. А можно ли освоить программирование, если усидчивость — не твоя сильная сторона?
Когда-то у меня был подопечный (назовем его Кирилл), которого я с абсолютного нуля учил программировать в 1С. Парень толковый, быстро освоил основы. Я начал давать ему первые реальные задачи и удивлялся скорости, с которой он их решал. Я еще пояснения к заданию договорить не успел, а от Кирилла уже слышал: «Владимир, у меня все готово». Только вот скоро выяснилось: все, что он делает, — работает неправильно или не работает вовсе. 🙂
Почему так получалось?
— ТЗ Кирилл читал по диагонали, и сразу кидался в бой (писать код). Вопросов у него не было, а если и возникали, то ответы он тут же придумывал сам.
— Он был абсолютно уверен, что результат работы программиста — это код, а не работающее решение.
— Пересмотр своего кода (я уже не говорю об изучении чужого) казался Кириллу совершенно пустой тратой времени.
Признаюсь, меня такой подход очень расстраивал. Иногда казалось, что хорошего программиста из Кирилла не выйдет, я зря трачу время. Но что интересно — он без возражений все переписывал, энтузиазм не пропадал. А это, я считаю, главный признак того, что все получится. Нужны просто четкие требования к результату и немного времени.
Я перестал проверять его решения после каждого «у меня все готово». Вместо этого последовательно задавал следующие вопросы:
🔻 Задание прочитал внимательно?
🔻 И тебе прям все-все ясно?
🔻 А решение сделал по всему заданию, ничего не пропустил?
🔻 Свой код перечитал?
🔻 Он точно соответствует заданию?
🔻 Оформил код правильно, красиво, по стандартам/регламентам?
🔻 А запускал его?
🔻 И как, работает? Проверил?
🔻 А работает как предполагается в задании?
🔻 Если неправильные данные ввести, не валится?
Каждый вопрос надо было проработать и утвердительно на него ответить. Качество решения уже получалось таким, что постановщик задачи при дальнейшей проверке хотя бы не ругался матом. 🙂
Опытному спецу эти вопросы могут показаться смешными. Но я вас уверяю, для некоторых начинающих программистов не очевидна даже необходимость запустить программу, чтобы все перепроверить...
Кирилл, кстати, сейчас работает в известной торговой компании программистом 1С. Говорил же, все получится!
Как относитесь к самостоятельной проверке результата работы?
👍 — обязательно перепроверяю.
🔥 — сразу делаю все правильно.
🤔 — чукча не читатель, чукча писатель, а проверкой пусть занимается тот, кто за это деньги получает.
#истории #кейсы
👍47🤔9🔥3
Взгляд на 1С со светлой стороны
— Платформа с широчайшими возможностями
— Конфигурации для любого учета
— Креативный вендор, который столько лет все это развивает
— Огромная сеть партнеров
— Множество отличных внедренцев и специалистов
— Благодарные пользователи
— Развивающийся с 1С бизнес
Взгляд на 1С с темной стороны
— Замкнутая ограниченная платформа
— Непонятные конфигурации, которые почти всегда нужно «допиливать»
— Негибкий вендор с давно устаревшими технологиями, политикой лицензирования и т.д.
— Жадные франчи
— По большей части бестолковые внедренцы и прочие 1С-ники
— Вечно недовольные пользователи
— Бизнес лучше развивался бы с другими системами, которые задавлены 1С
Какая сторона вам ближе?
👍 — светлая
🌚 — темная
🤔 — поровну
😐 — пока не определился с лагерем
#опросы
— Платформа с широчайшими возможностями
— Конфигурации для любого учета
— Креативный вендор, который столько лет все это развивает
— Огромная сеть партнеров
— Множество отличных внедренцев и специалистов
— Благодарные пользователи
— Развивающийся с 1С бизнес
Взгляд на 1С с темной стороны
— Замкнутая ограниченная платформа
— Непонятные конфигурации, которые почти всегда нужно «допиливать»
— Негибкий вендор с давно устаревшими технологиями, политикой лицензирования и т.д.
— Жадные франчи
— По большей части бестолковые внедренцы и прочие 1С-ники
— Вечно недовольные пользователи
— Бизнес лучше развивался бы с другими системами, которые задавлены 1С
Какая сторона вам ближе?
👍 — светлая
🌚 — темная
🤔 — поровну
😐 — пока не определился с лагерем
#опросы
👍48🤔30😐11🌚9😁3
На этом канале еще не было рекомендаций других каналов. И вот первая моя рекомендация: канал “Заметки 1Сницы”. Ведет его Анастасия – практикующий спец по 1С, программист, ментор. Ведет стажировки для начинающих 1С-ников. Пишет про вход в профессию, тонкости работы на позициях 1С-ников, публикует интервью с интересными спецами по 1С, директорами франчей.
Несколько запомнившихся мне постов:
📌 Секрет успеха 1С-ника (и не только)
📌 Должен ли программист знать предметную область и типовые?
📌 Как надо обучать разработке по версии меня
📌 FAQ "Хочу стать программистом, с чего начать?"
📌 Интервью с Алексеем Бояршиновым (директором Корады)
Еще Анастасия топит за то, чтобы компании не боялись брать и учить джунов, и многое для этого делает.
Рекомендую к подписке! 🔥
Несколько запомнившихся мне постов:
📌 Секрет успеха 1С-ника (и не только)
📌 Должен ли программист знать предметную область и типовые?
📌 Как надо обучать разработке по версии меня
📌 FAQ "Хочу стать программистом, с чего начать?"
📌 Интервью с Алексеем Бояршиновым (директором Корады)
Еще Анастасия топит за то, чтобы компании не боялись брать и учить джунов, и многое для этого делает.
Рекомендую к подписке! 🔥
👍13🔥7❤1
Как выглядит работа над проектом 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С Управление торговлей 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С, что, в свою очередь, существенно облегчило задачу. Все благодаря тому, что разработка мобильного приложения еще идет.
В результате уточненная оценка на второй этап (программирование) практически совпала с моей первоначальной. Ничего не подгонял, правда! Заказчик, кстати, все уже согласовал, хотя дешевле не получилось. А куда деваться, это уже не абстрактное число, все расписано подробно.
Сейчас приступаем к кодированию, ждите продолжение.
Традиционный опрос. Бодаетесь с заказчиками по трудоемкости/стоимости задач?
👍 — торгуюсь с азартом, как на арабском рынке
🔥 — приходится, но мне это дело не нравится
🤔 — не бодаюсь и не хочу.
#истории
🔥25👍12🤔10
Насколько быстро можно освоить программирование в 1С?
Продолжу тему входа в профессию. В этом посте рассказал, какими вопросами задаться программисту, чтобы проверить свое решение. А сегодня разберемся, сколько времени нужно, чтобы из начинающего 1С-ника превратиться в крепкого специалиста.
Обычно на такой вопрос отвечают, что все индивидуально. Само собой, это никому не нравится, ощущение, будто от тебя просто отмахнулись. Может, есть хотя бы примерный ориентир?
В книге «Гении и аутсайдеры» (написал канадский журналист Малкольм Гладуэлл) утверждается, что для достижения мастерства в любой сфере требуется 10 000 часов практики.
Что такое 10 000 часов? Это пять лет работы по 8 часов в день. По-моему, адекватный срок становления крепкого 1С-ника. Но при условии если:
– вы решаете реальные задачи, получаете «боевой опыт», а не только читаете книги или проходите курсы;
– вы сталкиваетесь с разнообразными задачами в различных конфигурациях, а не клепаете все время печатные формы под Бухгалтерию.
А что поможет вырасти побыстрее?
– Работайте не по 8 часов, а по 12 и без выходных. 🙂 Тогда 10 000 наберете раньше, но в подарок идет выгорание.
– Если у вас есть бэкграунд в программировании или решении учетных задач, считайте, часть пути вы уже прошли. Я, например, когда начал изучать 1С, уже многое знал о компьютерах, написал тонну кода на Pascal/Delphi, С++. И уверенно чувствовать себя в 1С стал гораздо раньше, чем через пять лет практики.
– Можно прибегнуть к помощи наставника, который научит мыслить правильно, подскажет, как решить задачу. Только чтобы не давал готовых решений — это вредно для роста.
Как оцениваете свою обучаемость?
👍 — могу самостоятельно освоить что угодно.
🔥 — легко, если есть хороший курс, учитель или компания.
🤔 — я и так все необходимое знаю, чему мне учиться?
#мнение_о_важном
Просто Про 1С
Продолжу тему входа в профессию. В этом посте рассказал, какими вопросами задаться программисту, чтобы проверить свое решение. А сегодня разберемся, сколько времени нужно, чтобы из начинающего 1С-ника превратиться в крепкого специалиста.
Обычно на такой вопрос отвечают, что все индивидуально. Само собой, это никому не нравится, ощущение, будто от тебя просто отмахнулись. Может, есть хотя бы примерный ориентир?
В книге «Гении и аутсайдеры» (написал канадский журналист Малкольм Гладуэлл) утверждается, что для достижения мастерства в любой сфере требуется 10 000 часов практики.
Что такое 10 000 часов? Это пять лет работы по 8 часов в день. По-моему, адекватный срок становления крепкого 1С-ника. Но при условии если:
– вы решаете реальные задачи, получаете «боевой опыт», а не только читаете книги или проходите курсы;
– вы сталкиваетесь с разнообразными задачами в различных конфигурациях, а не клепаете все время печатные формы под Бухгалтерию.
А что поможет вырасти побыстрее?
– Работайте не по 8 часов, а по 12 и без выходных. 🙂 Тогда 10 000 наберете раньше, но в подарок идет выгорание.
– Если у вас есть бэкграунд в программировании или решении учетных задач, считайте, часть пути вы уже прошли. Я, например, когда начал изучать 1С, уже многое знал о компьютерах, написал тонну кода на Pascal/Delphi, С++. И уверенно чувствовать себя в 1С стал гораздо раньше, чем через пять лет практики.
– Можно прибегнуть к помощи наставника, который научит мыслить правильно, подскажет, как решить задачу. Только чтобы не давал готовых решений — это вредно для роста.
Как оцениваете свою обучаемость?
👍 — могу самостоятельно освоить что угодно.
🔥 — легко, если есть хороший курс, учитель или компания.
🤔 — я и так все необходимое знаю, чему мне учиться?
#мнение_о_важном
Просто Про 1С
🔥34👍23🤔3🙏2