Кейс: как поставить доработки 1С на рельсы

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

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

Программисты 1С

В штате компании не было 1С программистов. Все доработки и техническая поддержка осуществлялась внештатным специалистом с почасовой оплатой. Но у некоторых сотрудников компании были сомнения в уровне компетентности данного специалиста. Жалобы были на некорректное выполнение заданий с первого раза и сложности в личной коммуникации.

У компании был выбор между наймом сотрудника в штат и попроектной работой с удаленными специалистами.

Мои доводы в пользу второго варианта:

• штатный специалист хорошего уровня будет дорогим для зарплатного фонда организации
• при этом его нужно будет постоянно загружать работой, а на данный момент нагрузки на полный рабочий день было месяца на 4-5
• высокая компетентность удаленных специалистов будет дешевле, так как за счёт насмотренности в разных проектах у них больше опыта
• удаленных специалистов проще искать, чем подходящего специалиста в офис в определенном районе города
• при неравномерной нагрузке можно нанять сначала несколько удаленщиков, затем постепенно сокращать их количество — с штатными сотрудниками это будет сделать сложнее

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

Первый же месяц работы с новым программистом подтвердил опасения сотрудников компании. Первый специалист действительно на похожие задачи тратил в 2-3 раза больше времени, при этом часто не закрывая задачу с первого раза из-за своих ошибок. Это оказалось хорошо заметно в сравнении с новым программистом. Поэтому от старого специалиста решено было отказаться.

Для обработки завала задач одного специалиста было недостаточно и я продолжил поиски. Но при собеседовании кандидатов выяснилась ещё одна проблема с 1С внутри организации.

Лицензии

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

В итоге с юридической точки зрения всё стало идеально. Весь комплект документов появился в наличии, на портале ИТЦ тоже стало всё в порядке.

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

Список задач

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

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

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

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

По каждой задаче я присвоил уникальный идентификационный номер, чтобы при обсуждении задач можно было проще и быстрее объяснить, про какую именно идёт речь. Дополнительно записал:

• дату постановки задачи,
• инициатора задачи,
• ответственного программиста,
• дату завершения задачи (пусто, если не готово),
• количество часов,
• стоимость для оплаты,
• дату оплаты.

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

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

Технические задания

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

Название файла совпадало с названием задачи. Дополнительно в самое начало названия ставился уникальный номер задачи. Таким образом внутри папки с ТЗ все они были отсортированы в порядке появления и можно было легко и быстро найти нужный файл.

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

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

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

Обновление платформы

Большой проблемой оказалась устаревшая версия платформы 1С:Предприятие, которую по рекомендации бывшего 1С-программиста не обновляли более 3 лет.

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

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

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

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

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

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

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

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

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

Отчетность

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

• количество новых задач за месяц
• количество закрытых задач за месяц
• количество отработанных программистами часов
• стоимость выполненных доработок

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

Но далее, с полноценным подключением всех трёх новых программистов, ситуация стала выравниваться. Потребовалось около 11 месяцев, чтобы выйти на хороший темп работы и закрыть почти все доработки. Как результат осталось менее 10 активных задач, что при текущей скорости соответствует 1 месяцу работы при условии отсутсвия новых задач.

Отчетность по каждому из программистов тоже стала нагляднее. В начале каждого месяца они присылали список номер задач, закрытых (выполненных, проверенных и утвержденных) за предыдущий месяц. По каждой задаче проставлялось количество часов. Этот список сверялся с данными из гугл таблицы и если расхождений не было, то программисты выставляли счёт, который затем передавался на оплату. Теперь по каждому программисту можно было посмотреть, сколько задач и когда он сделал, сколько на это потребовалось времени и сколько он получил за это денег.

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

Информационная система для постановки задач

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

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

• неразобранные задачи
• ближайший приоритет
• в работе
• на проверке
• готово

Эти этапы прописал в канбан-доске, далее создал карточки на каждую из задач из гугл-таблицы, включая даже уже закрытые задачи.

Настроил права доступа:

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

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

Для сравнения: наиболее активные инициаторы имели одновременно несколько задач в работе. Поэтому переписка между ними и мной, либо между ними и программистами часто включала в себя ненужный этап с объяснением, про какую именно задачу идёт речь. Условно, это выглядело примерно так: «добрый день, по поводу задачи с формированием коммерческого предложения — помните мы обсуждали с вами внешний вид файлов?». Теперь же контекст переписки был понятен сразу.

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

С помощью этапа «Ближайший приоритет» сотрудники могли сами выставить, какие именно из их задач нужно делать в первую очередь, а какие пока что подождут. Программисты при этом видели не только текущие задачи, назначенные на них, но и сразу 2-3 следующих задачи — это позволяет им лучше распланировать своё время.

Инструкции

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

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

Результаты

Было	Стало
Один программист	Три программиста
Тяжело найти специалиста	Легкий поиск новых специалистов
Инициатива сотрудников не реализовывается	Инициатива сотрудников реализовывается, 1С упрощает/ускоряет работу внутри компании
Устаревшая версия платформы затрудняет использование новых функций	Актуальная версия платформы с свежим функционалом
Отсутствие документации	Структурированная инструкция с описанием наиболее частых или важных функций
Отсутствие отчетности	Визуальные ежемесячные отчеты
Постановка задач устно в краткой форме	Постановка задач через подробные ТЗ с скриншотами с фиксацией в реестре задач
Утерянные документы лицензии	Полный комплект лицензионных документов