Экзорцизм программистскими методами 2

18.01.19

Управление проектом

Еще немного изгнания зла

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

Есть много материалов о том, как внедрение информационных систем помогло компаниям избавиться от потерь, сократить затраты, вырубить на корню воровство. Это прекрасно, когда получается избавляться от зла в таком большом объеме.

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

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

Просто опыт применения некоторых инструментов и примеры того, как они меня выручали.

Учет затрат на автоматизацию


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

Берем зарплату программиста и распределяем на решенные за месяц задачи. Получается стоимость решения конкретной задачи. Можно собрать по проекту, по заказчику, по подразделению.

Первый пример использования — защита от наездов типа «нами не занимаются, наши задачи не решают». Открываем отчет, смотрим — ага, на автоматизацию бухгалтерии компания потратила 250 т.р. за прошлый месяц. Или 1.5 млн. рублей в год, например.

Тут фишка в том, что оценивается в рублях — единице измерения, понятной директору. Если сказать «мы решили 113 задач от бухгалтерии», то он не проникнется — скажет, что надо еще больше делать. А когда говоришь «ты потратил 1.5 млн. на их задачи», ему будет неловко сказать «потратьте еще 2 млн. моих денег на них!». Чаще всего он вздыхал и спрашивал у бухгалтерии, что за задачи такие, на которые надо 1.5 млн. рублей тратить.

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

Мы решили вывернуть поинтереснее. В решенных задачах стали указывать не только заказчика, но и имена метаданных — документов, справочников и т.д., которые были созданы или доработаны при решении этой задачи.

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

А у нас затраты посчитаны. Допустим, это 30 т.р. Метаданные мы знаем, количество объектов знаем, делим одно на другое — получается, что в нашей системе на учет одного средства измерения потрачено 30 т.р. Хотя само средство измерения стоит 1 т.р.

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

Учет затрат на тех.поддержку


У нас на тех.поддержке сидел один человек — дежурный. Я от него часто слышал что-нибудь вроде «как же она достала, дура тупая, каждый день одно и то же спрашивает». Сначала не обращал особого внимания — мало ли, человек не запомнил, или мы виноваты. Потом, окольными путями, узнал, что некоторые пользователи сознательно устраивают DDoS-атаки на тех.поддержку, потому что не любят ИТ-отдел.

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

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

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

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

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

И вот есть бухгалтер, которому платят 30 т.р. в месяц, без учета налогов. И есть стоимость тех.поддержки, оказываемой этому бухгалтеру. Например, 20 т.р. в месяц — программисты же дорогие. Получается, бухгалтер обходится компании в 50 т.р. в месяц. Столько же стоит, например, заместитель главного бухгалтера.

Директор был немного ошарашен этими цифрами. Одно дело слышать «мы тратим 50 т.р. в месяц на тех.поддержку пользователей» — ну ладно, надо так надо. Совсем другое дело — «некомпетентность этого бухгалтера стоит нам 20 т.р. в месяц». Обращений на тех.поддержку стало меньше.
 

Незабывайка


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

Нас такой подход не устраивал, потому что все снова приходило к ситуации «программисты плохие». Поэтому мы поступили просто — начали использовать накопленную статистику затрат на автоматизацию.

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

Когда снова заходит разговор о том, что мы не решаем каких-то задач, или кто-то плохо автоматизирован, мы просто поднимали отчет, и показывали накопленную сумму. Т.к. у нас была статистика в разрезе метаданных, то сумма хорошо делилась на две части — хорошую и плохую.

Хорошая — используемый функционал. Плохая — неиспользуемый. У кого-то плохая была вдвое больше хорошей.
 

Парсинг версий


Системы версионирования, что в 1С, что в том же CouchDB, работают одинаково — просто хранят версии объектов на момент записи. Некоторые доделывают эти системы — например, не сохраняют версии, если ничего в объекте не поменялось.

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

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

Бухгалтеры, например, люди ушлые, но портить учет опасаются — если перезаписывают объект, то меняют какой-нибудь незначительный реквизит, вроде комментария. Формально, версия — новая, даже если фильтровать по наличию изменений.

Мы добавили такую сущность, как view осмысленности. Просто перечислили свойства объектов, изменение которых, скорее всего, является нормальным отражением работы человека, а не ИБД. Вьюшек было несколько, на один и тот же тип объекта. Например, изменение номенклатуры в отгрузке — это серьезное изменение. Изменение счета учета — так себе, не очень серьезное, но все-таки — работа. Изменение времени документа внутри одной даты — нет, увы, просто детское баловство.

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

У нас ведь есть возможность сравнивать версии не последовательно, а, например, первую и последнюю, и игнорировать промежуточные изменения. Когда квартал закрыт, документ, с высокой вероятностью, уже в целевом состоянии, и можно смело сравнивать его с последней версией на дату создания.
 

Корреляция автоматизации и KPI


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

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

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

Мы, как настоящие программисты, первым делом автоматизировали учет всех KPI. Те, что нельзя было рассчитать по данным системы, просто загрузили из экселя. У нас появились все цифры, характеризующие работу сотрудников и отделов компании.

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

Имея KPI и затраты на автоматизацию, очень просто посчитать корреляцию, потому что все данные хранятся с привязкой к датам. Выполнили, например, проект автоматизации стоимостью 200 т.р. в январе — должны измениться KPI соответствующего подразделения. Не сразу, а, допустим, в феврале, или в марте, или даже в июне. Но должны. Иначе в чем смысл?

Как ни странно, корреляция была. Например, в работе закупок — мы сделали проект автоматизации по ТОС, и их KPI выросли. Даже продажи выросли, т.к. именно они были целью автоматизации закупок, в конечном итоге.

Но были и примеры отсутствия корреляции. Например, внедрение CRM не принесло ничего, вообще. Создание сайта, взамен предыдущего, не принесло никакого эффекта.

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

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

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

Правда, потом директор сменился, и все пришлось начинать с самого начала. Но, где-то через полгода, новый директор тоже оценил расчет корреляции.

См. также

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    2989    0    biimmap    39    

38

Канбан и поставка ценности Программист Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бесплатно (free)

При разработке 1С:Бухгалтерии 8 используются унифицированные процессы обработки задач, построенные на методике Kanban. О том, как выглядит доска задач, в чем пишут код команды – в конфигураторе или в EDT, и что делается для повышения качества и понятности кода самого многопользовательского проекта фирмы «1С», пойдет речь в статье.

26.04.2024    4098    0    mrXoxot    5    

29

Канбан и поставка ценности Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Применение Agile в отделе разработки 1С:Бухгалтерии не сразу оправдало возложенные на него ожидания. Но только благодаря гибким методикам удалось стабилизировать выпуск релизов и перестроить разработку так, чтобы она всегда начиналась с анализа задачи и с общения с пользователями. Расскажем об квинтэссенции опыта разработки самого многопользовательского проекта фирмы «1С».

23.04.2024    3442    0    user1853337    8    

29

Кейсы проектов Руководитель проекта Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    3321    0    1СERP    21    

31

Кейсы проектов Программист Бизнес-аналитик Пользователь Руководитель проекта Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    15054    0    ASchekachev    37    

55

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    6169    0    stnslv    5    

25

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    5227    0    andironenko    3    

32

Компетенции и навыки РП Бизнес-аналитик Руководитель проекта Бесплатно (free)

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    5797    0    MariaTemchina    28    

22
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. citicat 119 18.01.19 11:05 Сейчас в теме
"В решенных задачах стали указывать не только заказчика, но и имена метаданных — документов, справочников и т.д., которые были созданы или доработаны при решении этой задачи."
Обоснование серьёзное. Чем больше цифр, тем большеее впечатление они призводят на читающего
2. nyam-nyam 18.01.19 11:10 Сейчас в теме
(1) Это не для раздутия отчетов сделано было, а для дальнейшей работы по учёту использования и расчёта стоимости в разрезе использования. Чтоб потом шельмовать шельмецов. :)
6. Vladimir Litvinenko 2888 18.01.19 13:45 Сейчас в теме
(1)
Вероятно, система учета задач интегрирована с основной учетной системой компании и может сама получить из неё статистику по количеству записей, созданных в базе данных по новым метаданным. Чтобы статистика была корректной скорее всего в отчетах учитываются именно созданные метаданные, а не изменённые. Хотя в публикации сказано в том числе про изменённые. Также система должна учитывать время на проектирование, реализацию и зарплату специалистов.

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

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

Система наверняка самописная и тянет данные из баг-трекера, основной учетной системы и какого-нибудь ЗУП.
3. citicat 119 18.01.19 11:54 Сейчас в теме
"внедрение CRM не принесло ничего, вообще".
Похоже на то, что в вашем бизнесе нет поддержки проданной продукции. Это же стеклопакеты, насколько я поняла, а не автоиобили с техобслуживанием.
Другой вопрос в базе СРМ, кто из покупателей создаёт рекламу, возможно, и случайно? Как -то это стоит учесть.
7. Petr54-ru 92 18.01.19 16:07 Сейчас в теме
(3) Если по-доброму, то перед внедрением CRM (как и любой другой фигни из трех букв) должны быть сформулированы и задокументированы цели внедрения, чтобы по завершению проекта мы поняли, достигли мы целей или нет.

И тут два варианта, либо на старте не пофиксили цели, либо те цели не были достигнуты.

Работал в одной компании, там директор как-то двинул мысли что нужна CRM, я спросил его про цели внедрения. Директор меня понять не смог. Я с другой стороны подхожу - типа я вам подготовлю табличку, со сравнением фич 1С конфигурации от Раруса и MicrosoftCRM, а вы выберете из этой таблички фичи, которые вам нужны, возможно будет проще эти нужные фичи просто дописать в УТ11. Так и не смог он выбрать нужные фичи, оказалось что у него совсем иная идея были - надо сначала внедрить CRM, а уже после внедрения понять, какую от нее можно получить пользу.

При такой постановке задачи провал гарантирован, поэтому пока я там работал, старательно уклонялся от запуска в работу проекта внедрения CRM.
shard; MCV; CheBurator; citicat; +4 Ответить
18. swimdog 767 19.01.19 14:32 Сейчас в теме
(7) А мы сейчас в CRM из экселя юристов пересаживаем. Казалось бы, причем здесь CRM? ))
19. citicat 119 19.01.19 17:08 Сейчас в теме
(18)
(18)Юристы по работе с базой данных не сильно грамотнее, чем кладовщики :). Им важен текст, распчатанный на бумаге, с подписями
сторон. Сочувствую
4. Aggressorak 18.01.19 12:22 Сейчас в теме
Во втором абзаце слово видимо пропущено.
"Есть много материалов о том, как внедрение информационных "технологий" помогло компаниям избавиться..."
5. 1c-intelligence 12825 18.01.19 12:30 Сейчас в теме
8. m_aster 112 18.01.19 16:09 Сейчас в теме
Некрасивая у Вас заставка, также и на аватаре. Оставили бы белька в покое, им и так достается от двуногих чудовищ. Кажется, это совсем не смешно.
12. 1c-intelligence 12825 18.01.19 16:57 Сейчас в теме
(8) тут надо контекст знать - игру "Overlord". Она старая, но попробуйте - увлекательно.
20. m_aster 112 20.01.19 10:13 Сейчас в теме
(12)Не все знают игру, но все видят картинку, к сожалению это происходит не виртуально, а вполне реально, с кровью и болью. В последнее время этого творится все в больших масштабах, как будто соревнуются между собой, кто больше! Я не хочу эту тему продолжать, я думаю, Вы все хорошо поняли, тем более у Вас такой ник(интеллект, интеллигентность, рассудок, понятливость..)
23. 1c-intelligence 12825 23.01.19 13:57 Сейчас в теме
(20) поменял картинку профиля. Буду флаконом.
24. m_aster 112 24.01.19 14:52 Сейчас в теме
(23) Наполните его знаниями, ценными не только для Вас, но и для других.
25. 1c-intelligence 12825 25.01.19 12:11 Сейчас в теме
(24) не подскажете, зачем? Есть куча людей, в головах которых - масса знаний, ценных для меня. Но от этого ни мне, ни им не холодно, не жарко.
26. m_aster 112 26.01.19 02:12 Сейчас в теме
(25) тогда не пишите здесь ничего, молча носите в своем флаконе, можете даже флакон не заполнять.
27. 1c-intelligence 12825 26.01.19 06:35 Сейчас в теме
(26) вы сказали флакон наполнять. Сейчас - не писать ничего. Что делать-то в итоге?
9. Glebis 13 18.01.19 16:18 Сейчас в теме
Совсем другое дело — «некомпетентность этого бухгалтера стоит нам 20 т.р. в месяц». Обращений на тех.поддержку стало меньше.

На мой взгляд, не обоснованная оптимизация с точки зрения руководителя предприятия, так как сэкономленные 20 т.р на консультациях с программистом могут привести к появлению ошибок в бухгалтерском учете, которые низкоквалифицированный пользователь допустит "...потому что 1С это позволило сделать... программисты это не предусмотрели... 1С кривая...на предыдущей работе таких ошибок не было...". Что в свою очередь может стоить предприятию гораздо больше 20 т.р., которые невозможно будет удержать с бухгалтера с ЗП 30 т.р..
11. 1c-intelligence 12825 18.01.19 16:56 Сейчас в теме
(9) это немного другая тема - управление качеством данных. Тут нужна проверка данных, фиксация, консилиум, или весь флакон сразу.
CheBurator; citicat; +2 Ответить
15. CheBurator 3126 19.01.19 14:09 Сейчас в теме
(9) Бухгалтер должен знать и уметь применять свой инструмент (ну, если просто - "чувствовать цифры". Компетентный бухгалтер даже по обобщенным данным видит некие несоответствия. И вполне может выйти на ошибку. И тут уже вопрос совершенно другой - бух отнес затраты не на тот счет который нужен. Почему? ответ бузха - так программа настроена. Ответ техотдела - мы не можем предусмотреть все возможные варианты и настроить 100 вариантов "типовых" выборов из значений возможных. Бух должен понимать, что он ввидил нетиповую, редко используемую а м.б. вообще новую "операцию".. и тупо бездумно колотить по умолчанию и плодить такие ошибки - не задача техотделда ставить везде затычки. Другое дело, чисто программные ошибки - прога ломается сразу - нет проблем, чиним. Или ошибки, которые приводят к неверным числовым значениям показателей. и если выручка за квартал 120 лямов, закупов не было, то НДС в сумме 28 лямов должен навести на вопросы... - а бухия работает еще хуже чем проги зачастух = "х..к, х..к по кнопкам, типа результат готов". Я у себя когда начался кипеж аналогичный (по более мелким поводам) сказал просто - "давайте оставим ГБ и замГБ, а всех остальных из бухии оформим как операторов ПК" - неееттт. не захотели, "булгахтер" - это же звучит гордо!
starponyx; +1 Ответить
10. acanta 18.01.19 16:22 Сейчас в теме
Найми 2х хороших бухгалтеров - сэкономь на программистах!
simgo83; Manoshkin; volkov_genadiy; +3 Ответить
13. volkov_genadiy_ 18.01.19 19:22 Сейчас в теме
Сереги на них нет. Не пришлось бы ничего придумывать. Серега быстро бы поставил их всех на место поиграв перед нимими в тетрис на телефоне все бы выпали в осадок от его мудрости.
MRAK; volkov_genadiy; plevakin; +3 Ответить
14. 1c-intelligence 12825 18.01.19 20:00 Сейчас в теме
16. CheBurator 3126 19.01.19 14:11 Сейчас в теме
Самое печальное вот это "Правда, потом директор сменился, и все пришлось начинать с самого начала. Но, где-то через полгода, новый директор тоже оценил расчет корреляции." - то есть приходится ЖДАТЬ (вполне возможно с ущербом для компании) пока гена созреет до понимания того, что бизнес - это цифры. и не только цифры денег и вала, но и прочие цифры В ОБЛАСТЯХ ОБСЛУЖИВАНИЯ БИЗНЕСА. а с цифрами - кто у нас работает...?
17. CheBurator 3126 19.01.19 14:12 Сейчас в теме
Несомненный плюс автору - то, что автоматизация показана на реальных примерах. В наше время - это дорогого стоит. Адски плюсую!
citicat; herfis; +2 1 Ответить
21. citicat 119 21.01.19 13:36 Сейчас в теме
"это ваша программа виновата" - придётся написать свою заметку о внедрении. Хотя пользователей в базе было не так уж много.
Программа виновата не больше, чем Кирилл и Мефодий, создавшие кириллицу.
Займусь на досуге.
22. Petr54-ru 92 22.01.19 17:15 Сейчас в теме
(21) С интересом жду вашей статьи.

Я в конце года тут выкладывал статью с подробным описанием своего микропроекта, - там эту тему тоже обойти не получилось. Цитата оттуда:

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


Вся статья
28. citicat 119 10.02.19 12:20 Сейчас в теме
(22) Написала статью про внедрение нескольких программ 1С:7.7 и программ тестирования отчетности.
29. adapter 418 30.09.20 22:35 Сейчас в теме
На самом деле интересная статья и примеры хорошие. Но я вот подумал про обратную сторону медали... Тратится время на KPI всего и вся. Время программистов и руководителей подразделений. Пользователи придумывают новые способы сломать систему. Снова тратится время на защиту KPI. А кто то считал сколько человеко-часов уходит на эту войну? Можно в деньгах )

Строятся цифровые крепости, заградительные системы. Поглощается все больше ресурсов. Метрики! нам нужно больше метрик!
Бухгалтер чем больше проводок сделал, тем больше з.п. получил? Закрытие месяца - одну кнопку нажал, з.п. х3 получил. Странно что им не нравится )

А то ведь как бывает, директор давит сверху:
- почему не сделали двойную норму? Кто виноват?
- ну не мы же, и так, работаем до ночи. И не вы же, если двойную хрень требуете. Значит IT-шники виноваты, у них 1С медленная )

И понеслось, метрики, скорость замеры, оправдания. А директор почему давит? Потому что не понимает нифига дебет\кредит, какие там проблемы у вас? - не, не понимаю я по вашему ) И делегировать не умеет - вокруг все так и ждут чтобы его обмануть, а сами лодыри и тупицы.

Есть ведь и добрый ламповый способ. Мотивация, партнерство, результаты. Или компании на другом уровне развития.
Оставьте свое сообщение