Специфика внутренней разработки

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

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

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

На платформе СПО

Специфика бизнеса консалтинговой группы «Руна» обусловила ее интерес к процессному управлению. Постоянно растущий объем административных регламентов требовал развития ИТ-поддержки бизнес-процессов. Как рассказывает Михаил Орлов, председатель совета директоров компании, первоначально эта задача не представляла сложности и решалась посредством использования папок Microsoft Exchange: в папку, соответствующую первому шагу процесса, выкладывалась записка с заданием, исполнителю направлялось сообщение электронной почты с уведомлением, затем исполнитель вручную переносил записку в следующую папку бизнес-процесса и так далее до последней в процессе папки. Папки шагов вложены в родительские папки бизнес-процессов, а те, в свою очередь, — в папки групп бизнес-процессов на уровне отделов. Полный доступ к ним был у хозяев данных процессов, которые проектировали и создавали необходимую структуру папок. Они же контролировали ход выполнения процессов, то есть перемещения записок с заданиями. Необходимо отметить, что такой способ может быть с успехом использован небольшими организациями, которые, например, находятся на начальном этапе развития и не могут выделить средства на приобретение или разработку специализированной системы. Однако, как это произошло с компанией «Руна», по мере усложнения структуры бизнес-процессов данный подход перестает быть пригодным.

Проект разработки ПО с открытым кодом RunaWFE начался в сентябре 2003 года. Финансировала его сама консалтинговая группа «Руна», которая решила внедрить у себя систему управления бизнес-процессами и административными регламентами. Зрелых российских программных продуктов тогда, по словам Орлова, на рынке найти не удалось, а иностранные стоили от 450 до 2000 долл. за одно рабочее место. Кроме затрат на покупку системы, заметных расходов потребовало бы и внедрение проприетарной системы, а также обучение пользователей и техническая поддержка внедренного продукта. Поэтому было решено сделать ставку на одну из свободно распространяемых workflow-систем на основе лицензии LGPL. Сыграло роль еще и то, что в компании на большинстве пользовательских компьютеров использовались терминальные решения. Примерно в половине случаев они работали под управлением Linux в минимальной конфигурации. В результате в качестве платформы было выбрано решение JBPM, которое развивается сообществом JBOSS, специализирующимся на разработке программного обеспечения промежуточного слоя на основе Java. Летом 2004 года началась разработка кода системы силами ИТ-департамента компании.

Очень важно было сохранить статус СПО для ведущейся разработки. Орлов отмечает, что, в соответствии с требованиями открытой лицензии на компоненты, из которых собиралась система (лицензия LGPL ), полученное в результате решение тоже должно было стать программным обеспечением с открытым кодом. В ноябре 2004 года на портале sourceforge.net была опубликована первая версия кода системы. В июне 2005 года появилась демоверсия, доступная в режиме онлайн. В конце 2005 года в Интернет была выложена первая версия редактора бизнес-процессов. В конце 2006 года разработка базовой конфигурации системы была закончена. С января по июнь 2007 года система прошла промышленное тестирование, после чего была переведена в промышленную эксплуатацию.

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

По мнению Орлова, к числу наиболее важных требований к разрабатываемым бизнес-приложениям следует отнести разработку документации, в частности, по установке и конфигурированию, а также по регламентным процедурам. В отличие от коммерческих проектов во внутренних проектах на этом нередко экономят, что приводит к многочисленным проблемам. Безусловно, разрабатываемое ПО должно учитывать сложившуюся в данной компании практику использования вычислительных ресурсов (в случае с КГ «Руна» это распространенность терминальных режимов). Если речь идет о разработке системы управления потоками работ, то необходимо предусмотреть наличие редактора бизнес-объектов или утилиты отображения объектов на бизнес-объекты, а также заложить в систему возможности оперативной масштабируемости в широких пределах. В «Руне» была преду­смотрена масштабируемость по пользователям в два раза, по количеству транзакций — в четыре раза и по количеству объектов — в десять раз. Прочие требования весьма стандартны — возможность резервного копирования и восстановления и т. д.

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

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

Минимальный функционал, отвечающий потребностям

Во многих случаях, считает Борис Климов, руководитель группы внутренних разработок компании «Лаборатория Касперского», руководитель организации занимает позицию стороннего наблюдателя, заявляя примерно следующее: «Вам система нужна — вы и внедряйте» или «Вы специалисты — вы мне и скажите, в чем состоит польза для организации данной системы». Это порочная практика, полагает Климов, она приводит к появлению системы с функционалом, который никем не используется. В лучшем случае интерес и реальные требования появляются позже, когда система начнет развиваться, но ресурсы, уже потраченные на нее, израсходованы впустую.

По мнению Климова, основная проблема ИТ-департамента в непрофильной организации — зависимость бюджета от интересов внутренних заказчиков. Каждое внедрение или разработку необходимо защищать и убеждать руководство, что это им необходимо. Всегда есть тот, кто платит, тот, кто предъявляет требования, и тот, кто будет пользоваться результатом работы. В таких организациях необходимо убедить потенциального спонсора (того, кто будет финансировать разработку), что ему это выгодно. Как это сделать? Используя язык денег — в данном случае он универсален, любое требование бизнес-заказчика можно связать с доходами и расходами, а, как известно, язык денег хорошо понимает любой руководитель. Даже если создаваемая информационная система не позволяет зарабатывать, может быть, она дает возможность экономить, повышать качество, увеличивать объем и т. п. В конце концов неважно, какую программную систему разрабатывать, важно выразить перспективы ее использования в денежном эквиваленте, например в терминах совокупной стоимости владения и окупаемости. Кроме того, необходимо сформировать у бизнес-заказчика правильные ожидания, объяснив ему, что любое внедрение, автоматизация и т. п. всегда первоначально приводят к снижению производительности, а ожидаемый в денежном выражении результат появляется только спустя время.

При формировании требований главный посыл должен исходить от руководства организации. ИТ-специалист не должен придумывать, что может потребоваться или что могло бы быть интересно руководству. Руководителям различных уровней (в идеале всех уровней, которые будут использовать систему или результаты ее работы) необходимо сформулировать свои потребности. И только на их основе, по мнению Климова, специалист сможет создать формализованный свод требований к информационной системе.

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

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

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

Бывают случаи, когда разработчику приходится превращаться в инженера поддержки или в оператора на первой линии Help Desk. Такого следует избегать, говорит Климов, хотя бы из экономических соображений. На первую линию можно нанять студента-стажера, который минимум вдвое-втрое дешевле, а пользу сможет принести сравнимую. Каждый должен заниматься своим делом: разработчик — разрабатывать, тестировщик — тестировать, а руководитель — управлять. Подмена ролей или их временное совмещение возможно, но нежелательно. Климов говорит: «Меня, руководителя группы, посадить на первую линию поддержки равносильно тому, что в багажнике «Бентли» перевозить картошку с огорода». Это можно сделать, но как минимум это непрактично. Кроме того, такая замена является сильным демотивирующим фактором. Однако это вовсе не значит, что разработчика нельзя привлекать к решению инцидентов тогда, когда действительно необходимо, — например, на второй или третьей линии поддержки или на стадии активного внедрения, когда количество заявок в день вырастает в разы. Подобная трансформация возможна, но в исключительных случаях, как временное решение и на очень короткий период

Что касается пользовательского интерфейса, то его проектирование в инсорсинговой разработке, по мнению Климова, отражает «совокупность лени разработчика или команды и учет редких требований к интерфейсу будущих пользователей». Традиционно удобству интерфейса уделяют мало внимания, когда речь заходит о внутренней разработке, на этом стараются сэкономить (как, впрочем, и на тестировании). Таким образом, юзабилити внутренней разработки — это скорее результат обучения пользователей, их привыкания.

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

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

«Я много раз убеждался, что разработка какого-либо бизнес-инструмента с нуля всегда дороже покупки готового — при условии, что такой на рынке уже есть», — отмечает Климов.

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

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