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

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

Поскольку в то время я выполнял еще и иные функции, которые требовали не менее 80% моего времени, на первого программиста я возлагал большие надежды. Это должен был быть человек, способный сделать все самостоятельно – собрать команду, разработать архитектуру, написать систему и упаковать в дистрибутив. Ага. За 1 000 долларов.

В общем, к концу 2006 года я нашел студента последнего курса одного из алматинских ВУЗов. Романтика, витающего в облаках (в то время облака означали еще взвешенные в атмосфере продукты конденсации водяного пара, а не cloud computing). Эти облака в будущем создали для меня немало пасмурных дней, зато солнышко ценить научился.

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

В результате, ситуация продолжала топтаться на месте вплоть до мая 2007 года. К тому времени итоги теоритических изысканий романтика откровенно напоминали описание тупика коммунизма, и даже мне стало понятно, что пора брать быка за рога. Из положительных достижений за истекший период отмечу увеличение бюджета на этот непонятный проект (кстати, тогда это хозяйство называлось Манускриптом; Документолог появился в 2008 году), и прием на работу еще двух программистов. Студентов предпоследних курсов алматинских ВУЗов.

В мае 2007 года происходят два события. Во-первых, понимая, что дальше так продолжаться не может, я высвободил свободное от основной работы время для того, чтобы наконец-то заняться Манускриптом. Во-вторых, именно тогда у меня родилась идея конструктора, который сегодня, можно сказать, что даже с некоторым успехом, применяется в Documentolog’e и Detrix’е. Идея родилась в попытке декомпозиции документа (или того, что я тогда понимал под документом) на составные части. В результате такой разбивки получились:

1. Атрибуты (Поля) документа.
2. Поля документа образовывали визуальное отображение документа (или карточку) при помощи Шаблона.
3. Действия, о которых ниже.
4. Маршрут, о котором еще ниже.

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

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

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

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

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

После отдела кадров документ направится на точку Утверждение у главного босса, потом инициируется создание проекта приказа и т.д.  Думаю, что идея точек маршрута понятна.

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

(Собственно, только что я кратко описал идею модели систем Documentolog и Detrix. Это и есть то, что отличает их от других собратьев на рынке. В какую сторону отличает, поговорим как-нибудь в следующий раз.)

Базовый костяк идей был отработан мной на протяжении мая – июня 2007 года (хотя с барсеткой я ходил еще, как минимум, год), а с 1 июля мы наконец-то приступили к «разработке».

Продолжение и окончание