I ВСТУПЛЕНИЕ

Из хаоса каким-то образом рождается порядок.
Некоторые об этом узнают из газет со значительным опозданием, а некоторые по горькому опыту на месте и в процессе создания этого порядка.
Михаил Булгаков.

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

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

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

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

II ОПРЕДЕЛЕНИЕ ГРАНИЦ ПРОЦЕССА ПРОИЗВОДСТВА ИНФОРМАЦИОННЫХ СИСТЕМ

По мере того, как сложность возрастает, точные утверждения теряют значимость, а значимые утверждения теряют точность.
Лотфи Заде

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

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

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

В-третьих, Программное Обеспечение (далее ПО) такого уровня требует и использование оборудования под стать, включая: распределенные системы хранения данных, средства безопасности и т.п. Для построения, развертывания и поддержания работоспособности комплексов такого масштаба необходимо и мероприятия организовывать с соответствующим размахом.

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

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

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

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

Определив вкратце масштабы «бедствия» и узкие места процесса производства больших информационных систем, проследуем непосредственно к самой процедуре.

III НАЧАЛО

Чёрт знает, чем всё кончится, но хорошо, что хоть начинается.
Анджей Сапковский (Крещение огнем)

История создания программного продукта может начинаться по-разному. Но в любом случае, должно наличествовать, как минимум три важных проявления:

1. Потребность в его создании (кому-то он действительно нужен);
2. Возможность его создания. (кто-то может его реализовать);
3. Возможность финансирования его создания (кто-то может оплатить).

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

1. Потребность создания продукта

Проще всего стартовать, когда надобность в программном продукте настойчиво возникает у самого потенциального пользователя, и он к тому же способен вразумительно выразить свои пожелания к этому самому продукту. В подобном случае в игру вступает аналитик. Этот сотрудник может величаться как: Бизнес-аналитик, Бизнес-архитектор или Менеджер-продукта. Выявляя пожелания клиента, он кропотливо собирает их в описание Концепции целевого программного продукта. Это весьма непростое занятие, поскольку на самом деле вытянуть из потенциального пользователя, что же ему действительно надо, ой как не просто. Ведь приходится сумбурные, разрозненные хотелки клиента подчинить единой значимой цели, достижение которой и принесет ощутимый эффект от автоматизации его деятельности. Для решения таких задач нужен и обусловленный склад характера, и определенные профессиональные навыки. Мои рекомендации по проведению этой процедуры можно почитать в публикации Практика формирования требований в ИТ проектах от А до Я. Часть 1.

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

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

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

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


Рисунок 1. – Определение потребностей заказчика при производстве программного продукта

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

Далее, в ходе погружения в техпроцесс, мы будем постепенно дополнять данную модель.

2. Возможность создания продукта

Когда сделан первый шаг, и становится более-менее очевидным, что же именно должен получить заказчик в результате порождения нового программного продукта, в дело вступают Архитекторы уровня Solution, занимающиеся технологическими аспектами проектов. Они помогают оценить примерные сроки и ресурсы, необходимые для создания программного продукта, в общих чертах обрисованного в документах на предыдущей стадии работ. В свой черед предлагаются различные варианты для выбора технологических решений, влияющие на показатели: качество, ресурсоемкость, сроки реализации и т.п. Эти активности, в зависимости от ситуации, также могут выполнять Team Lead (технический лидер команды) – играющий тренер в многопрофильных командах, или SEM (Software Engineering Manager) специализированный менеджер, как правило, не работающий непосредственно с кодом.

Предложенные решения могут быть зафиксированы в уже более детальный документ — Концептуальное представление или Видение разрабатываемой информационной системы.

На этом отрезке может происходить подбор команд, которым будет доверено создание компонентов программного продукта.

Добавим элементы в нашу модель на рис. 2.


Рисунок 2. – Формирование концептуальной модели для производства программного продукта

3. Возможность финансирования создания продукта

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

Естественно, чем точнее претенденты, номинированные на роль создателей продукта, смогли уловить потребности и настроения заказчика и выразительнее донесли до его сознания картинку своего решения, тем больше шансов получить положительный ответ. Это ключевой момент данного этапа!

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


Рисунок 3. – Оценка проектного решения при производстве программного продукта

4. Возможность финансирования стартапов

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

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

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

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

5. Резюме раздела

Для старта процесса создания программного продукта, в одном и том же месте, в один и тот же временной период, должна сложиться совокупность трех составляющих:

1. Потребность в его создании (кому-то он действительно нужен);
2. Возможность его создания. (кто-то может его реализовать);
3. Возможность финансировать его создание (кто-то может оплатить).

В результате активностей первого этапа производства программного продукта должно появиться:

• Понимание, концепции продукта, кому и зачем он нужен;
• Понимание кто и как может его реализовать;
• Первичная оценка затрат на его реализацию;
• Наличие источников финансирования для его создания и дальнейшего развития.

Рисунок 4. – Артефакты, порождаемые этапом подготовки к производству программного продукта.

IV ЮРИДИЧЕСКОЕ ОФОРМЛЕНИЕ ВЗАИМООТНОШЕНИЙ МЕЖДУ УЧАСТНИКАМИ ПРОИЗВОДСТВА ИНФОРМАЦИОННОЙ СИСТЕМЫ

Устный договор не стоит бумаги, на которой он написан.
Самуэль Голдвин

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

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

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

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

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

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


Рисунок 5. – Артефакты, порождаемые этапом оформления договорных отношений

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