В прошлой статье “Что такое компьютерная информационная система” я поднял важный вопрос о базовых понятиях и понимании терминологии при взаимодействии пользователя (заказчика) и программистов. Как и обещал, я продолжаю раскрывать эту тему. И хочу рассказать о правильном планировании процесса разработки и внедрения программных продуктов.
По роду своей деятельности я постоянно сталкиваюсь с проектной работой. И на старте любого проекта я сталкиваюсь со трудной задачей грамотного планирования. Почему это так важно? Хороший план – это практически половина успеха. Без планирования практически невозможно выстроить работу четко, слаженно, добиться поставленных целей и уложиться в оговоренные сроки. Особенно это важно, если речь идет о командной работе.
В принципе, о важности планирования написано очень много. И я здесь не буду повторять всем известные истины. Все просто: если вы знаете, куда вам нужно прийти и сумеете проложить верный маршрут, вы достигните цели. Если нет – увы, никто не сможет заранее угадать, куда вы в итоге придете.
Любой план достижения цели должен учитывать такие факторы:
Если речь идет об объектах материального мира, например, о строительстве дома, все сравнительно просто. Есть заказчик, который рассказывает свои пожелания. Есть участок земли с определенными особенностями. Есть строительные материалы с различными параметрами и стоимостью. И есть определенный бюджет. Исходя из этого определяется итоговый вариант проекта, смета, планируются этапы работ. Даже если вы никогда не сталкивались со строительством, вы видели много домов, в том числе, в процессе стройки. Результат – материален, как и внешние факторы. Потому выбор решения и составление плана редко вызывают сложности.
При работе с компьютерными информационными системами вы сталкиваетесь с проблемой отсутствия материальных факторов и результата. Здесь не получится, как, например, при выборе фундамента для дома, опираться на однозначные исходные данные и законы физики. Кроме того, внедрение каждого программного продукта – это уникальный проект.
Каждый коллектив, как и каждый человек, по-своему уникальны. И них всегда есть свои, особые потребности и пожелания. Разработку и внедрение программного обеспечения для того и заказывают, чтобы получить решение «под себя», когда существующих типовых программ оказывается недостаточно.
При планировании проекта в сфере IT необходимо:
И только после этого можно переходить к составлению плана действий. При этом заказчиком может выступать любой человек, коммерческая или некоммерческая организация. Главное, что всегда есть тот, кто заказывает проект и будет им в будущем пользоваться.
Практика показывает, что как раз подготовительная работа с заказчиком часто вызывает сложности. И здесь на помощь может прийти подход, основанный на определении:
Компьютерная информационная система – это идея, выраженная посредством языка программирования.
Подробное описание и обоснование такого определения я давал в статье «Что такое компьютерная информационная система». Для лучшего понимания рекомендую ознакомиться всем, кто еще ее не читал.
Первое и наиболее очевидное, что нужно понимать: чтобы выбранный или созданный под заказ программный продукт соответствовали вашей идее, необходимо сочетание двух факторов:
И на этапе однозначного и понятного третьим лицам описания идеи проекта очень полезными оказываются, так называемые, BPM схемы. Иначе говоря, графические нотации описания бизнес-процессов. Подробнее с тем, что это такое и как составляют BPM нотации вы можете ознакомиться в моей статье «Что такое бизнес-процесс и описание бизнес процесса».
При этом важно понимать, что здесь речь идет совсем не обязательно о бизнес-процессах, при помощи инструментов BPM можно успешно описывать любые трудовые и другие виды процессов, т.е. наглядно моделировать варианты воплощения идеи.
Для описания бизнеса или выполнения какой-либо задачи могут применяться два подхода – процессный и функциональный. Об их отличиях и особенностях я также уже подробно писал в статье «Моделирование бизнеса. Основные подходы».
При поиске решения (формулировке самой идеи) многие предпочитают функциональный вариант моделирования. Он помогает для себя понять суть задачи и необходимые для ее решения инструменты. А для эффективного решения поставленной задачи и составления плана работ, как показывает мой личный опыт, оптимально подходит процессное моделирование.
Как это делают:
Для успешного составления BPM нотации человек должен обладать определенными знаниями:
При сотрудничестве с бизнесом или некоммерческими организациями процесс сотрудничества строится следующим образом:
В отдельных случаях формулировка задачи в целом и детализация могут быть выполнены одним достаточно информированным обо всех важных нюансах человеком.
Далее, полученное описание оформляется в виде графической нотации, где также присутствует несколько уровней детализации. Их число зависит от сложности системы.
Следующий этап – уточнения и согласования. Здесь уже готовую нотацию изучают руководители и сотрудники организации, при необходимости, вносят уточнения. На этом же этапе возможны изменения в деталях самой идеи, которые помогут оптимизировать работу, в том числе, на уровне сотрудников и взаимодействия подразделений. Здесь важно понимать: графическая модель помогает увидеть многие «шероховатости», ненужное дублирование функций и т.д. И, конечно, при формулировании идеи в виде нотации, можно и нужно обсудить эти недостатки рабочего процесса и продумать, как их оптимизировать.
У вас уже есть согласованная и детализированная идея, воплощенная в виде графической нотации. Что очень важно – нотация прошла все обсуждения, руководство компании подписало окончательный вариант. Можно с уверенностью в достигнутом взаимопонимании приступать к выбору или созданию программного продукта.
В наше время для коммерческих и некоммерческих организаций крайне редко приходится писать программные решения «с нуля». Это дорого и долго. Тем более, что для большинства идей существуют готовые (типовые) решения, которые достаточно настроить и/или немного доработать.
И здесь очень важно из всех подходящих по тематике и функциональности программных систем нужно выбрать ту, идея которой максимально соответствует идее заказчика.
Например, идея звучит так: «нужна автоматизация работы отдела продаж».
Этап 1. Для реализации лучше всего подходит CRM-система. Эти программные решения разрабатываются специально для отделов продаж.
Этап 2. Из всех существующих CRM нужно выбрать те, функционал которых максимально подходит под выбранный алгоритм работы (реализацию идею).
Этап 3. Выбор из составленного списка подходящих CRM заключается в изучении их дополнительного функционала: готовых решений для интеграции с другими программными продуктами, наличие встроенных полезных для идеи инструментов, соотношение цены/качества.
При этом важно понимать: в реализации любой идеи люди являются неотъемлемой частью процесса. И если они не примут выбранное решение, то программный продукт при всех его достоинствах с точки зрения разработчиков, окажется неподходящим для реализации идеи.
Более того, описание бизнес-процесса (воплощения идеи) – это, прежде всего, описание деятельности людей. Идеи относятся к человеческой деятельности. Автоматизация здесь только вспомогательный фактор. А потому любое описание бизнес-процессов – это, прежде всего, описание работы людей. И только потом – техническая часть вопроса.
К сожалению, я на практике встречался с ошибочным подходом, когда BPMN нотация полностью посвящена технической части и, по сути, является альтернативным вариантом написания алгоритма для программистов. В этом случае люди и их взаимодействие с программными решениями оказываются «за кадром». И при внедрении решения на практике часто возникают накладки и недоразумения. В результате идея реализуется долго, сложно. Или оказывается провальной. Просто потому, что при ее описании забыли о важнейшем факторе – действиях людей.
Подробней о нотациях BPMN, основных элементах и принципах их использования, а также практический пример вы можете изучить в моей статье «Краткое описание BPMN с примером».
Больше примеров будет в следующих публикациях.