8.5. Как наладить эффективное взаимодействие с программистами

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

Наиболее популярных вопросов по большому счету всего три:

1. Кто должен писать техническое задание на доработку – бухгалтер или программист?

2. Как бороться со срывом сроков? Переходим, переходим на новую версию, а перейти все никак не можем.

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

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

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

Для его ведения можно использовать MS Excel или специализированное программное обеспечение, предназначенное для осуществления технической поддержки пользователей (системы Help Desk).

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

Все запросы делятся на три группы:

1. Требования к результату (например, исправить что-то в алгоритме расчета НДС в соответствии с изменениями в законодательстве).

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

3. Требования к процессу (например, время формирования отчета по дебиторской задолженности сократить в два раза).

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

Таблица 8.2. Реестр запросов на доработку бухгалтерской программы

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

Что же касается проволочек, то приведу показательный пример. На одном предприятии собственные программисты в течение нескольких лет внедряли «восьмерку» и никак не могли закончить внедрение. Потом они вдруг неожиданно сказали, что эта программа для компании не подходит и нужно переходить на «Галактику». Представляете себе состояние главного бухгалтера? Она уже несколько лет промучилась, живя в этом переходном периоде, а теперь оказывается, что все зря. Я ей посоветовал «ложиться на рельсы» и не допустить еще одного долгостроя. Пусть доделывают то, что начали. Ведь проблема не в информационной системе, а в программистах.

Девять из 10 резюме программистов написаны в формате «что делал», а не «что сделал». Поиграли с 1С:8.0 – надоело, теперь хочется поиграть с «Галактикой». И никакой ответственности за результат. Не мучайтесь с плохими программистами – ищите хороших. Их мало, но они есть. Те самые, которые «один из десяти».

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

Почему так происходит? Все очень просто. Тем, кто ратует за своих, посчастливилось заполучить в штат хорошего программиста. Или, что более вероятно, не повезло со сторонними. И наоборот тот, кому повезло со сторонней фирмой, а не со штатными программистами, – активный поборник аутсорсинга.

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

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