Почему тормозит 1С? Большое расследование

Почему чаще всего тормозит 1С

 

Эта статья будет не технической. Техническую информацию о том, почему 1С может работать плохо и что с этим делать, можно получить на различных курсах. Здесь пойдет речь о вопросах более высокого уровня. Сразу скажу: все это – мое личное мнение.

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

• Как выстроить современный CI/CD конвейер

• Полноценное ревью разработки и архитектуры

• Тестирование в том числе производительности

• Минимизируют промахи при проектировании

• Быстро найдут и устранят узкие места, если возникнут

• Проектирование, разработку, внедрение выполнят на высоком уровне, с минимальными рисками что «не взлетит»

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

 

Кого считать сеньором в вопросах производительности

 

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

Возьмем некоего 1С-специалиста, который 20–30 лет занимался 1С, но работал с маленькими компаниями, небольшими базами и низкой нагрузкой. Теперь ему дали базу объемом несколько терабайт и сотни или тысячи пользователей. Через какое-то время система повиснет. Возможно, он сам ее повесит своими доработками и не сможет объяснить, что происходит.

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

Допустим, у человека есть сертификат 1С:Специалист – он доказал, что умеет хорошо программировать, но пока не подтвердил квалификацию, необходимую для работы с большими базами и высокой нагрузкой. А есть сертификат 1С:Эксперта. Его обладатель подтвердил, что умеет работать с большими базами и высокой нагрузкой. По большому счету, вам нужно сделать так, чтобы такой специалист работал с вами постоянно, а не наскоками.

 

 

Условно квалификация 1С:Специалиста подтверждает, что человек умеет программировать и в определенном объеме знает типовые конфигурации.

 

 

Квалификация 1С:Эксперта – это стопроцентное знание программирования и администрирования, около 70% знаний DBA по PostgreSQL или MS SQL Server и в некотором объеме знания системного администратора. Это очень глубокий профиль, поэтому неудивительно, что такие специалисты нередко занимают руководящие, чаще технические, должности.

Экзамен сдают немногие, потому что сдавать его сложно. Таких специалистов в десятки раз меньше, чем 1С:Специалистов. Но, с другой стороны, крупных заказчиков у нас тоже не так много.

Итак, в контексте производительности будем называть сеньором 1С:Эксперта, а 1С:Специалиста – мидлом. Именно в контексте производительности: есть и другие навыки, по которым можно давать другие оценки.

 

Где нужны 1С:Эксперты

 

Кого считать крупным клиентом и где нужны специалисты, которых мы будем называть сеньорами?

С точки зрения фирмы «1С», у крупного клиента около 500 пользователей на сервере 1С: в этом случае нужно покупать КОРП-лицензию. Сколько таких заказчиков, фирма «1С» не раскрывает. Зато у нас есть данные налоговой, которая приводит количество микропредприятий, представителей малого, среднего и крупного бизнеса:

• Микропредприятия 6,6 млн компаний (до 15 чел, до 120 млн выручка)

• Малый бизнес 232 тыс компаний (до 100 чел, до 800 млн выручка)

• Средний бизнес 22 тыс компаний (до 250 чел, до 2 млрд выручка)

• Крупный бизнес ~20 тыс компаний (свыше 250 чел, свыше 2 млрд) точное число не найдено в открытых источниках

• Оборот свыше 5 млрд имеет более 7600 компаний

Сколько сейчас в России крупных клиентов? Спойлер: эксперты работают именно с крупным бизнесом. Таких компаний порядка 20 тысяч, причем далеко не со всеми эксперты работают на постоянной основе.

Почему может тормозить 1С у малого и среднего бизнеса и почему она может тормозить у крупного?

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

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

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

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

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

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

 

Какие компании готовы работать с экспертами постоянно

 

С точки зрения фирмы «1С», крупный клиент – это более 500 пользователей на сервере. С точки зрения налоговой – компания с оборотом от двух миллиардов рублей.

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

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

По имеющейся статистике, 80% клиентов РКЛ имеют выручку более двух миллиардов рублей. Среднегодовая выручка клиентов РКЛ – более 20 миллиардов, медиана – около 80 миллиардов. Это те данные, которые удалось собрать по моим клиентам и клиентам коллег.

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

 

Почему у крупного клиента может тормозить 1С

 

 

Если посмотреть на объем рынка крупных клиентов, то малый и средний бизнес составляют основную массу компаний. Экспертов там почти нет, они появляются редко. Условно еще в 5% компаний эксперты могут привлекаться, чаще всего разово.

 

 

Примерно в 3% компаний эксперты могут работать постоянно – в штате или на постоянной технической поддержке.

Итого около 8% компаний можно считать крупными. С ними могут работать джависты, специалисты по высоконагруженной веб-разработке, искусственному интеллекту, анализу данных и Big Data. 1С-специалисты же работают и в этих 8% крупных компаний, и в остальных представителях малого и среднего бизнеса. Это очень важный момент, который нужно учитывать при найме.

Почему у крупного клиента 1С может работать плохо? Потому что там нет специалистов, которые умеют работать с большими системами. Наняли специалистов, умеющих работать с маленькими системами.

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

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

Если просто опубликовать вакансию программиста 1С, откликаться будут в основном специалисты, которые работали с небольшими системами. Можно попытаться вырастить специалиста внутри команды, но он дорастет до определенного уровня, а потом все равно попросит больше денег или уйдет.

 

Как строят карьеру 1С-специалисты

 

1С-специалисты догадываются, что есть другие IT-специальности, представители которых ездят на Bentley. Почему же все они не уходят в другие направления?

 

 

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

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

 

 

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

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

 

 

Есть еще рейтинг экспертов, созданный совместно с фирмой «1С». Нам удалось найти две трети специалистов из этого рейтинга. Выяснилось, что в основном это руководители: начальники отделов, технические и IT-директора. Даже архитекторов среди них оказалось не так много.

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

• Технический директор

• Руководитель разработки

• Технический архитектор, Системный архитектор

• Техлид

• Директор по разработке, архитектуре

Это не мои домыслы: именно так их нанимают. По-другому привлечь такого человека сложно.

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

Для найма лучше использовать HR-специалистов, которые специализируются на поиске сотрудников для 1С. Если взять обычного HR, он будет ориентироваться на среднюю температуру по больнице, и нужного человека вы будете искать очень долго.

 

Почему эксперт не всегда может работать

 

Допустим, эксперт у вас появился, но почему-то не может работать. Частая причина – отсутствие необходимых доступов из-за политики безопасности.

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

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

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

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

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

И, конечно, нужно выращивать собственных специалистов.

 

Как объяснить бизнесу ценность производительности

 

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

 

 

Евгений Филиппов подсказал, что в таком случае делать. Есть всем известная методика APDEX, а Евгений расширил ее и придумал методику «Баблокс» – простую систему привязки проблем к деньгам. Нужно показать, сколько денег будет терять бизнес, если система начнет тормозить.

Есть компании побольше и поменьше. Условная граница – около двух миллиардов рублей оборота и 500 пользователей на сервере. Компании, которые доросли до этой границы, часто проходят несколько стадий.

 

 

Первая стадия – гнев. В этом случае все пытаются навалить на какого-нибудь штатного 1С-специалиста или администратора: «Давай разбирайся, это твоя 1С и вообще твой сервер». Люди к таким вопросам не подготовлены, но пытаются справиться своими силами.

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

Следующий этап – торг. Заказчик уже принял, что система стала большой и с ней надо что-то делать, но начинает торговаться с самим собой или с несправедливой судьбой. Ищет простые решения и лазейки: «Давайте купим оборудование, спросим у Google, сами всему научимся, проведем аудит».

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

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

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

 

 

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

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

Например, IT-директору в очередной раз объясняют: «Возьми человека на четыре-шесть месяцев на аутстафф или по срочному трудовому договору. Он все починит и сделает намного лучше». Человек внимательно выслушивает, но есть проблема – дцать лет в IT. Он много лет работает в отрасли, поэтому сам знает, что делать.

 

 

Решение такое: провести много аудитов, спросить много экспертов, собрать все рекомендации в одну кучу – и тогда получится супер-рекомендация.

 

Зрелые и незрелые решения

 

 

Следующий переходный этап – «Коробочкины решения». Мы хотим подешевле, попроще и пытаемся убедить себя: может быть, система у нас не очень большая, не очень многопользовательская и не очень нагруженная? Давайте как-нибудь попроще.

Зрелое решение – нанять высококвалифицированного специалиста, схантить его, предложив больше. Использовать профильных специалистов: экспертов по производительности, специалистов по интеграции и так далее.

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

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

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

Как вы думаете, у кого, скорее всего, будет тормозить 1С?

 

Что делать крупному клиенту

 

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

Если крупных задач достаточно много, держите 1С:Эксперта на лидирующей или руководящей позиции.

Есть простой признак: если вы уже доросли до найма DBA, но основной объем данных у вас приходится на базу 1С, имеет смысл нанять еще и эксперта либо взять эксперта вместо DBA.

Если задачи возникают нечасто, используйте экспертное совместительство – хотя бы на 0,2 ставки. Еще один вариант – заключить договор на комплексную техническую поддержку с компанией, в которой есть эксперты. В состав такой поддержки могут входить консультации, обновления и работа с производительностью. Это тоже сильный вариант.

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

Google, зависимость от аудитов и выращивание многостаночников – слабые варианты.

 

Где скрывается больше всего проблем

 

Больше всего проблем не в волшебных настройках, а в программном коде.

 

 

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

Здоровье подобных конструкций в первую очередь зависит от квалификации программиста.

Каким путем можно пойти? Можно улучшать качество программного кода, а можно уменьшать его количество.

 

Как улучшить качество программного кода

 

Сейчас популярно внедрение полноценного CI/CD-конвейера для разработки в 1С.

Как это связано с производительностью? Есть SonarQube или его аналог в 1С – АПК. Они позволяют выявлять простейшие проблемы производительности с помощью анализа кода, но эксперта не заменяют. Такие инструменты быстро находят часть детских болезней и облегчают работу. При этом ручное ревью со стороны эксперта обязательно.

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

Что можно сделать на практике? С помощью той же Vanessa Automation можно подготовить эконом-вариант. Это не полноценное нагрузочное тестирование.

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

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

Эконом-вариант можно немного расширить. Полноценным нагрузочным тестированием это все равно не станет. Для него существуют отдельные курсы.

В эконом-варианте берем 20–40 пользователей – небольшое количество – и без учета реальной частоты выполнения прогоняем основные операции, которые пользователи обычно выполняют в системе. Затем сравниваем нагрузку с эталонной.

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

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

И, конечно, программистов нужно обучать стандартам разработки.

 

Как уменьшить количество программного кода

 

Уменьшение количества программного кода может показаться неожиданным решением.

Если программисты общаются напрямую с пользователями, то очень часто сразу после получения задачи начинают писать код. Не задумываясь: может быть, уже есть что-то готовое или похожее? Нужно ли вообще это делать? Сколько это будет стоить?

Реальный пример: группа программистов долгое время дорабатывала систему, на тот момент УПП. В итоге стоимость каждого обновления в ценах 2015 года составила 800 тысяч рублей – почти миллион. Сейчас было бы дороже. Затем пришла новая команда и удалила большую часть доработок. Оказалось, что они были не нужны.

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

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

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

Другому человеку несколько раз запрещали писать код и все переписывать. Он сделал вид, что сдался, но по вечерам и выходным все равно все переписал. Потом пришел и сказал: «Я все равно переписал, но сделал это бесплатно, в нерабочее время». Не мог человек по-другому.

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

 

Моя личная боль

 

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

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

 

 

Например, база объемом около 400 ГБ была разделена по организациям. Половину данных я вынес в другую базу с контролем ссылочной целостности. В результате нет битых ссылок, а вся операция заняла 35 минут.

 

 

Другой пример – база «Бухгалтерии» объемом 4,5 ТБ. За четыре часа были введены остатки, свернуты с контролем ссылок документы, журналы и регистры. В базе оставили данные за три года, обработали 107 объектов 1С.

 

 

Рекорд – база ERP, объем которой уменьшили с 9 до 2,5 ТБ. Операция заняла три часа. За это время были введены остатки, с контролем ссылок свернуты все необходимые документы и регистры всех видов. Были удалены данные примерно за две трети времени существования базы.

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

В какой-то момент я подумал: «Теперь я вроде бы умный. У меня есть экспертиза и отлаженный инструмент, который я много раз проверил. Пойду кому-нибудь его предложу».

Я предложил решение пяти крупным компаниям – системным интеграторам и крупным франчайзи. Общался с руководителями департаментов, директорами и собственниками. Но все они оказались бывшими программистами и сказали: «Иди лесом со своим решением, мы за пару часов сделаем то же самое».

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

Почему? Потому что руководители – бывшие программисты и привыкли мыслить так: нужно написать код.

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

Что они делают? Пишут собственную версию ERP, которая лучше, чем ERP от «1С». Замахиваются на свой браузер и почтовый клиент, подумывают о собственной СУБД.

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

 

Менеджер между пользователями и программистами

 

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

 

 

Этот менеджер должен настойчиво задавать вопросы:

• «Зачем это вообще делать?»

• «Может быть, не будем?»

• «Разработка окупится?»

• «Сколько это будет стоить?»

• «Сколько стоят твои часы?»

• «Сколько времени это займет?»

• «Можно ли использовать похожее решение?»

• «Можно ли взять готовое решение?»

• «Есть ли человек, у которого уже есть опыт решения такой задачи?»

А потом нужно еще раз подумать: может быть, все-таки не надо этого делать?

Во-первых, речь идет о бюджете. Во-вторых, доработки – самая частая причина проблем с производительностью. Чаще всего 1С тормозит именно из-за некачественных доработок.

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

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

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.