Как избежать разработки учетной Зомби-системы. Часть 2

Мы разрабатываем open-source базу данных для не-программистов. Вот про нее статья на VC или вот репозиторий на GitHub.

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

Часть 1 — здесь

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Еще один реальный пример: скажем, для заведения новой категории товара необходимо подтверждение менеджера. Кладовщик завел, менеджер ушел в отпуск, игнор, запой – и не подтверждает. Кладовщик пишет в техподдержку, мол, подтвердите, а то у меня работа стоит. Со стороны техподдержки велик соблазн все подтвердить и забыть, потому что у них есть нормативы по обработке каждой заявки. В отличие от игнор-менеджера, который если уж если ушел в запой, то не останавливаться же (утрирую, но бывает). И разовые такие подтверждения возможны. Но в целом неоднократно на опыте доказано, что стратегия должна быть другой.

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

Прочитав эту статью (а тем более в комплекте с предыдущей) вы можете сделать вывод, что быть как разработчиком, так и заказчиком ПО – чистое страдание, которое неминуемо закончится зомби-апокалипсисом.

Некоторое страдание в процессе разработки присутствует, и иногда создание зомби-системы неминуемо: например, если компания находится вне конкурентного поля (например, различные госструктуры). Но если организация стремится конкурировать и зарабатывать, тернистый путь автоматизации достаточно быстро приводит к ощутимым финансовым результатам, ради которых стоило постараться.

P. S. Мы там PRO бесплатно раздаем за звездочки на GitHub.