Сегодня мне пришлось задаться этим вопросом.
Вам когда-нибудь приходилось внедрять процесс автоматизации организационных процессов с нуля? А применяя научный подход? И при этом взаимодействовать с заказчиком (руководителем подразделения) абсолютно "из другой области, отличной от технической"? Когда заказчик еще и хочет не только получить результат, но и активно участвовать, ставить задачи и контролировать работу? Нет?! Странно...
Но кроме шуток, мне пришлось с этим явлением столкнуться. Руководитель (заказчик) не может (или не хочет) довериться специалистам, контролировать сроки и ожидать результат, он хочет вникнуть во все детали.. быстро вникнуть.. за час-два где-то, чтобы уже вами командовать самостоятельно, а не просто доверять вашему профессионализму. Ну, чтож, похвально. Вот, только для этого мне необходимо "обучить" заказчика основам автоматизации, а именно из чего строится весь этот непростой процесс, и какие знания и навыки при этом необходимы.
Вот, что у меня получилось.
В любой автоматизации есть несколько ролей: крайне редко бывает так, что один человек совмещает несколько из них или даже все. Это роль:
- заказчика
- системного аналитика
- программиста
Заказчик является носителем знаний о функционале, который необходимо автоматизировать. В лучшем случае он даже представляет себе детально процесс. В худшем - знает как работать "как-то так, как получается", не выстраивая особо каких либо логических последовательностей выполнения работы, не утруждая себя причино-следственной связью между действиями участников процесса.
В классической модели заказчик должен предоставить формальное описание бизнес-процесса в виде схем (нотаций схем бизнес-процессов множество, их выбирают в каждой организации "под себя", что удобней). Но, как правило, это тоже редкость.
Системный аналитик по предоставляемым схемам пишет составляет бизнес-требования к автоматизации (БТА) со слов заказчика (если, конечно, заказчик может логично и детально их сформулировать, что на практике оказывается тоже проблематичным). Далее на основе полученного БТА аналитик составляет техническое задание (ТЗ) под разработку для программиста: другими словами, переводит бизнес-требования на язык программирования в виде алгоритмов и графических интерфейсов, учитывая, безусловно, технические условия работы будущего программного обеспечения как самостоятельного, так и в интеграции с уже существующими системами.
При этом, желательно, чтобы заказчик понимал, что в результате деятельности системного аналитика получается - совпадает ли с его ожиданиями, и верно ли передается информация программисту. В противном случае, на выходе будет не совсем то, что хотелось или вовсе не то.
Ну, и наконец, дело программиста (или группы программистов) - все реализовать и передать на тестирование заказчику и системному аналитику. По результатам внести необходимые коррективы и завершить автоматизацию, то есть передать в эксплуатацию.
Все было бы хорошо, если считать, что заказчик:
- умеет строить бизнес-процессы (если проект вообще с нуля, и процесса как такового еще нет) или уже является обладателем работающего и формализованного бизнес-процесса;
- понимает работу системного аналитика и может квалифицировано сформулировать бизнес-требования в рамках системы, а не только краткосрочных задач;
- видит все причины и следствия своего процесса, понимать все условия и ограничения процесса, взаимодействия между участниками процесса;
- понимает и знает, как можно оптимизировать процесс: где можно реализовать с помощью автоматизации, а где нет - представлять четко себе цель автоматизации, представлять себе конечный результат автоматизации и понимать, как ее достичь;
- понимает принципы и основы работы программиста: понимать как описание преобразуется в ТЗ, чтобы быть вполне уверенным, что ваши требования дошли до программиста в нужном виде, а также в случае чего скорректировать работу программиста.
В моем случае, ни один из пунктов не выполнен. Такое бывает. В этом случае помогает решить задачу автоматизации специалист, заменяющий собой заказчика. Он взаимодействует и с заказчиком, и с аналитиком, и с программистом. Он отвечает за конечный результат проекта - является руководителем проекта, организует работу всей проектной группы.
Какими же навыками и знаниями, на мой взгляд, обладает данный специалист?
- В области системотехники и формальной логики - необходимо для написание бизнес-процесса любой деятельности, так как необходимо "видеть" систему целиком со всеми ее взаимосвязями, логическими входами и выходами, чтобы не было "оборванных концов". Проблема в написании бизнес-процессов неумение определения границ процесса и его подпроцессов, неправильное акцентрирование на частном, но не общем, целом.
- Знания принципов алгоритмизации - необходимо для написания бизнес-процесса в виде стройной и логической схемы с учетом всех условий и ограничений. Умение разрабатывать алгоритмы на нескольких уровнях глубины процесса.
- Знание основ алгоритмических языков программирования. Это дает возможность не только понимать, как словесное описание бизнес-требований перевести в техническое задание, но и мыслить уже в рамках автоматизации, а не только "желаний и пожеланий". Эти знания помогают взаимодействовать с программистом, говорить на его языке.
- Если говорить о реализации проекта в целом, то не помешает знать как организовать работу проектной группы, как управлять временным ресурсом (планирование работы) - здесь я использую сетевое планирование, как управлять выделенными ресурсами (это, если ресурсы берутся у других подразделений, а такое часто бывает), как контролировать работу и получать результат.
- Знание принципов процессного управления. Как не крути, а автоматизировать можно только уже формализованный процесс. Поэтому важно понимать в целом данную методологию.
У меня получился, собственно, портрет специалиста-системотехника. Большая часть знаний получено мною в вузовском образовании. Это фундаментальные знания. Обучить заказчика в короткий срок - час-два - практически невозможно, если он, скажем из сферы HR. Но я попробую :).
Собственно, этот пост родился в результате моих размышлений на эту тему - как научить заказчика понимать сложный процесс автоматизации, чтобы и он мог "говорить на этом языке". В одном я убедилась довольно быстро, что не зная основ, нельзя понять всего остального. Надо с их и начинать. Пытаться объяснить сложные вещи без "азбуки" на метафорах и примерах бесполезно. Правда, есть надежда, что если объяснить, что нужно знать и уметь для работы с автоматизацией, заказчик таки решится довериться и просто ждать, ориентируясь на выставленные сроки...