CustisWiki - Новые страницы [ru]

SECR-2008 (Отчет Стаса Фомина)

2010-01-19T15:46:16Z

BenderBot: 1 версия

GDD2009 (Отчет Клинчаева Олега)

2010-01-15T15:06:01Z

BenderBot: 1 версия

PHP-разгон: серебряная пуля из автомата Комменца-Вальтера (Commentz-Walter)

2010-01-12T17:15:53Z

StasFomin: /* Видео */

Рабочее название: «PHP-разгон: серебряная пуля из автомата Комменца-Вальтера» (Commentz-Walter)».

«Разработка концепции ПО» (семинар UML2.ru)

2009-12-31T16:49:40Z

StasFomin:

26 ноября в нашей компании прошел семинар «Разработка концепции ПО», проводимый в рамках серии семинаров сообщества системных аналитиков UML².ru.

Ведущими были две Ирины: Векленко и Сурова, а аннотация гласила:

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

Понятие концепции (vision). Место концепции в жизненном цикле разработки ПО

Взаимосвязь концепции с артефактами проекта по разработке ПО

Структура концепции

Примеры документа «концепция» в различных методологиях разработки ПО

А у нас все не так! (ответы на вопросы)

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

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

И в результате, удалось увидеть разнообразие концепций — от солидного документа в ворде и составленного совместно с заказчиком кластера статей в вики системе, до простых двух абзацев в Google Docs.

Действительно, бывают концепции строго оформленные по шаблонам «самого Вигерса», из которых ничего невозможно понять, и не приводящие к живым проектам (на встрече рассматривали такие примеры^[2]). А как забавный пример обратного, можно привести историю известной (в узких кругах) игры «EnviroBear2000», успешно реализованной^[3] по одному концепту-абзацу (оригинальная цитата полностью, орфография авторская): «Здраствуйтє, сдєлайтє пажалуста ігру шоб можна била мєдвєдєм кушать ягади і рибу. Да, і шоб мєдвєдь єзділ на машинє. І шоб фізіка била рєалістічная: можна тараніть дєрєв”я, падают шишкі, лістья, оси, скунс. Скунс бєгаєт па машинє, но єво можна схватіть лапай — і викінуть с машини. А іщьо — нада шоби єзділі па лєсу другіє мєдвєді на машинах. С німі можна будєт тараніцца. Всє ричат. На паваротах машину далжно занасіть. Руль крутіть можна лапай. І главнає — шоб нє как в аркадах — пєрєклучєніє пєрєдач ручноє. Ну й пєдаль тада тоже можна лапай жать. Когда мєдвєдь єст рибу — абязатєльна далжни аставцца кості і хвост. Чєрєз пять мінут наступаєт зіма.»

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

↑ «Oh Brother, Where Art Thou?»
↑ См., например, [1]
↑ Адский видеогеймплей можно посмотреть например тут, легко найти и скачать саму игру. А здесь можно увидеть и другие примеры «гениальных концептов геймплея» уровня «можно грабить корованы»

AgileDays-2009 (Technical excelence)

2009-12-18T19:21:53Z

StasFomin:

Представляем краткий отчет и обзор докладов, прошедших на третьем, техническом треке «Technical excelence» конференции AgileDays.ru.

Вообще, мы (Стас Фомин и Андрей Бибичев) осуществляли организационно-техническую поддержку докладов в секции «Technical excelence», в частности, мы сняли и публикуем обработанное видео. Сделали что смогли — цветокоррекция, темпоральная фильтрация шумов, усиление границ (для большей читаемости слайдов), в звуке — нормализация и динамическая компрессия. Некоторую реверберацию (эхо), увы, убрать не удалось (уж очень это трудоемко), сорри.

Видео публикуем и в виде флешвидео (640x512) и отдельно можно скачать видео в оригинальном качестве (720x576). Мы специально оставили изображение слегка вытянутым — и максимум площади из максимально возможного квадрата 640x640 используется, и буквы читаются легче, и люди стройней и симпатичней). Для пары докладов «лекционного» типа, не сильно зависящих от слайдов, мы сделали и аудиоподкасты.

Да, если судить о докладах третьего трека по оперативным отзывам в микроблогах, то отзывов о докладах с остальных треках больше, но это не потому, что доклады тут были самые унылые — просто организованный бесплатный WiFi не добивал до третьего этажа, где проходил трек «Technical excelence», а писать отзывы с мобильников все-таки у нас не так много энтузиастов. К тому же, отзывы в твиттер о конференции, на уже выходят из моды, см. Совет № 3.

Содержание

1 Обзор Agile
2 Обзор Feature-Driven Development и Domain-Driven Design
3 Увидеть лес за деревьями
4 Внедрение Agile
5 8-битный Scrum
6 ОО дизайн: SOLID принципы
7 MS Team System vs IBM Rational Jazz: лучший инструмент разработчика
8 TDD + DDD + MVP + GoF + PoEAA = Love!

Обзор Agile

Докладчик: Никита Филиппов

http://agiledays.ru/reports/themes/view/26/

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

На этом докладе мы рассмотрим:

Плюсы и минусы других процессных подходов: Waterfall, Code & Fix.
Принципы Agile: Anti-code & fix, Anti-Waterfall
Практики Scrum
Чем можно улучшить Scrum?

Это собственно изложение азов ценностей и практик Agile-движения и SCRUM-а в частности, и несмотря на азбучный уровень, доклад оказался весьма полезным. Ведь с одной стороны, на конференции с названием AgileDays, да еще проводящейся не в первый раз, да еще и по теме, которой вроде как уже несколько лет общеизвестна в индустрии, можно было бы ждать, что «все в теме», и «буквари» вроде как издевательство над аудиторией. Но судя по вопросам, в зале было полно людей из параллельных вселенных «мира Дилберта и роговолосых», так что этот доклад оказался незря.

Так что если вы «в теме» — то, скорее всего, ничего нового их этого доклада вы не узнаете. А вдруг слова «Agile» и «SCRUM» незнакомы (или знакомы, но в сомнительном изложении типа «слышал я Карузо…, Рабинович вчера напел…») — то посмотрите или послушайте. «Послушайте» — в смысле эту лекцию можно слушать даже без слайдов — мы выложили подкаст:

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Обзор Feature-Driven Development и Domain-Driven Design

Докладчик: Андрей Бибичев

http://agiledays.ru/reports/view/4/

Эрик Эванс (Eric Evans) в своей книге о Domain-Driven Design (DDD) пишет: «Software development is all design» (Разработка ПО — это всецело дизайн/проектирование). И правда: ведь сборка ПО целиком автоматизируется и не требует ощутимых усилий со стороны проектной команды.

И что же в Agile есть на тему дизайна/проектирования? Scrum об этом молчит. В eXtreme Programming (XP) есть такие практики, как Test-Driven Development (TDD) и Refactoring, но они работают, скорее, на уровне дизайна отдельных классов и их имплементации («микро-дизайн»). А как же быть с архитектурой и «макро-дизайном»?!

«Лучшие собаководы» (гуру архитектуры и проектирования) рекомендуют сочетать проектирование сверху-вниз и реализацию снизу-вверх, то есть макро- и микро- дизайны. Agile-процесс под названием Feature-Driven Development (FDD) как раз базируется на таком подходе. В докладе дается краткое описание как самого процесса, так и его истории. Проводятся параллели с XP и Scrum, дается анализ сильных и слабых сторон, а также области применимости.

Казалось бы, причем здесь Domain-Driven Design (DDD)? В FDD краеугольным камнем является модель предметной области (Domain Model). В DDD — тоже. Но если FDD — это прежде всего процесс, то DDD является подходом к проектированию и реализации, причем этот подход замечательно сочетается с любым Agile-процессом. Кроме того, в DDD много внимания уделено «сшивке» макро- и микро- дизайнов: описаны общие принципы имплементации модели в программном коде, приводятся готовые образцы (patterns) реализации.

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

Андрей убеждал не останавливаться на тупом, «карго-культовом», внедрении SCRUM-практик, уподобляясь кальсонным гномам, а обязательно развивать архитектурные практики, такие как Domain-driven design и Feature Driven Development, настаивая, что для достаточно большого проекта (от 20 человеко-лет) это не «модное дополнение к SCRUM», а именно необходимый ингридиент.

В целом, аудитория была в теме — достаточно заметить, что на конференции был десант из Нижегородского Интела, где ребята выступали с близким по теме докладом #TDD + DDD + MVP + GoF + PoEAA= Love!, так что четверть часа после доклада шла дискуссия (есть на видео), на темы:

Как избежать анемии доменной модели и бизнес-логики — классически инкапсулировать бизнес-логику в объекты или выносить ее на сервисный слой?
Как должны соотноситься уровень Infrostructure и Domain? Должен ли Domain классически использовать Infrostructure (возможно разделяемую на несколько проектов с разными предметными областями), или, в соответствии с новыми веяниями использовать паттерны «Inversion of Control/Dependency Injection», и Domain ничего не должен знать о Infrostructure, что несколько необычно, но должно давать большой буст при тестировании (можно разгонять тесты, mockiруя тяжелый инфраструктурный слой).
Оправдано ли экономически, играть во все игры с модными паттернами и практиками — понятно, что все это ради качества, но какой ценой? Может это могут позволить себе только очень богатые компании, для inhouse-разработки, или крупные компании для продуктов с огромными тиражами, но ведь в обычной заказной разработке дилемму «скорость-качество», невыгодно радикально решать в пользу последней.

Дискуссия также продолжилась и в онлайне. Присоединяйтесь к ней, если есть конструктивные замечания.

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Увидеть лес за деревьями

Докладчик: Стас Фомин (CustIS)

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

Однако на практике возникает проблема — как быстро и эффективно исследовать этот пласт информации?

Читать логи переписки и коммиты в VCS? То есть разрабатывать «шахту знаний» киркой и мотыгой? Бродить по лесу и считать деревья?
Посчитать метрики? Ненавистные SLOC и иже с ними? В зависимости от глубины детализации можно получить:
- либо пару унылых метрик («KSLOCs в месяц на сферического разработчика в вакууме», то есть в нашей метафоре максимум — «площадь лесного массива»),
- либо многостраничные Excel-dashboardы, заполненные мириадами цифр, в которых почти также бессмысленно лезть человеку, если он не профессор Чарли Эппс из сериала Numb3rs с его верными суперкомпьютерами и волшебными алгоритмами DataMining-a.

Что же делать?

Есть альтернативный способ «увидеть лес за деревьями» и при этом выжать краткую информацию по процессу — Визуализация.

Итак,

Мы покажем модель визуализации коллективной разработки ПО.
Представим portable-фреймворк для такого исследования, адаптированный для максимальной простоты использования — все работает из коробки, просто скормите ему вашу историю.
На выходе — музыкальные ролики визуализации! Их можно смотреть как с исследовательскими целями, так и для удовольствия, радуя себя, команду, и, возможно, приманивая новых сотрудников.
…
PROFIT! Фреймворк раздадим всем бесплатно, и никто не уйдет обиженным!

Собственно, все, о чем был доклад, мы выложили в open-source, и все это можно свободно и быстро попробовать (скачать и запустить на любом проекте — работает из коробки) — ShowTeamWork.

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Внедрение Agile

Докладчик: Павел Афанасенко

http://agiledays.ru/reports/themes/view/27/

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

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

Докладчик — известный консультант по вопросам внедрения Agile-практик (SCRUM, eXtreme programming,…), рассказал о нетривиальных проблемах реального внедрения этих практик. Кстати, эту лекцию тоже можно вполне прослушать в отрыве от слайдов:

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

8-битный Scrum

Докладчик: Алексей Омельянчук (Сигма-ИС)

http://agiledays.ru/reports/themes/view/7/

Можно ли использовать гибкие методологии на предприятиях по производству микроконтроллерных устройств? Оказывается, можно!

Представьте, что разработка включает в себя не только написание ПО, но и создание аппаратной платформы, на которой оно будет исполнятся. Более того, процессоры преимущественно используются 8-разрядные, а языки разработки — ассемблер и «чистый» С. Как использовать в этом случае Scrum?

Автор доклада обобщит свой опыт внедрения Agile в трех различных компаниях:

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

Для всех 3-х предприятий характерна выраженная специализация разработчиков, необходимость синхронизации разработки аппаратной и программной части и «размазанный» по нескольким командам Product Owner.

Автор расскажет о том, что сработало, а что не получилось и о том, как помогло применение отдельных методов Lean Development и максимальный упор на раннюю полномасштабную демонстрацию.

Обычно, при словах SCRUM всплывает некоторый стереотип — программисты пишут заказной софт (информационная система, скорее всего с вебинтерфейсом) на основе мощных библиотек и фреймворков, легко удовлетворяя метания бизнес-пользователей за счет заложенной гибкости архитектуры, наслаждаются кроссфункциональностью (в смысле смеются, когда дизайном занимается хардкодер, но в целом все ОК), с энтузиазмом играют во все developers games (ибо в РФ, программист — пока профессия молодых).

А что если нет не то, что лишних пары гигабайт для вечноголодной Жавы, а вообще, есть только 512байт ПЗУ и 32 байт ОЗУ? А если рабочий стол программиста занят не тремя 24" мониторами, а тестерами (в смысле приборами, а не девушками), осциллографами и паяльником? Если специалисты настолько матерые и узкие, что о кроссфункциональности не может быть и речи, а из-за их возраста «standup meetings» приходится отказать?

По опыту докладчика (на основе работы в трех различных производствах, связанных с микроэлектроникой), в таких условиях SCRUM постепенно мигрирует к Lean-практикам, типа Kanban, но некоторые практики SCRUM сохраняют свою ценность в любых условиях.

Например, частые демонстрации. Интересно, судя по вопросам, в зале были специалисты из микроэлектронной индустрии, и на их жалобы вида «Как делать регулярное демо (нового прибора), если поставщик только через квартал сможет дать нужную деталь (индикатор)» — докладчик парировал — «Стыдитесь! Для демонстраций и тестирования ~~используйте mock-объекты~~ подключите обычный компьютер с симулятором».

Из отзывов наших сотрудников:

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

Команда его прошла путь от производственного предприятия работающего на МО с жестким Rational Unified Process, через крупного частного производителя контроллеров (крупнейший поставщик АвтоВаза, 2 млн штук в год) до software-предприятия, занимающегося, в основном, программированием, а не железом. На каждом этапе добавлялись новый практики.

Что используются

спринты, ограниченные во времени
демо (по признанию докладчика практика оказалась самой полезной)
планирование. Причем, планируют 120—140 % от запаса времени, с разделением на обязательное и бонусы

Длительность спринта составляет 1 месяц, что было связано со сложившимся на предприятии укладом. Также был «мегаспринт» — 3 месяцы. Эта цифра обусловлена

обновлением реального железа
высокое руководство имеет возможность приезжать на демо с такой периодичностью.

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

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

ОО дизайн: SOLID принципы

Докладчик: Дмитрий Кандалов (Deutsche Bank)

http://agiledays.ru/reports/themes/view/17/

В этом докладе я расскажу о SOLID принципах ООП описанных Робертом Мартином (Robert C. Martin) в книге «Быстрая разработка ПО: принципы, паттерны, практики» (Agile Principles, Patterns, and Practices) и что они означают в реальной жизни. Некоторые из этих принципов широко известны в других формах, некоторые очевидны. Но их интерпретация Робертом Мартином одна из лучших и может быть очень полезна для программистов использующих ОО языки.

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

Принцип единственности ответственности (The Single Responsibility Principle)
Принцип открытости/закрытости (The Open Closed Principle)
Принцип замещения Лисков (The Liskov Substitution Principle)
Принцип разделения интерфейса (The Interface Segregation Principle)
Принцип инверсии зависимости (The Dependency Inversion Principle)

Кстати, если скучно читать эти сухие определения, то посмотрите на набор веселых «демотиваторов» по этой теме. А докладчику дарим бесплатную идею — при следующем выступлении, добавить эти демотиваторы к слайдам.

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

MS Team System vs IBM Rational Jazz: лучший инструмент разработчика

Докладчики: Евгений Злобин (Microsoft) и Тимур Маркунин (IBM)

Как следует из названия, ожидалась совместная презентационная сессия сейлов Microsoft и IBM. Те, кто в кулуарах даже ожидали sales battle, боюсь были несколько разочарованы — никакого экстремального маркетинга не случилось, была последовательная презентация близких по смыслу продуктов, но никакой войны — докладчики очень благожелательно относились друг к другу, иногда даже в ответах на вопросы рекомендуя продукт конкурента.

В некотором смысле разгадка проста. Продукты эти весьма недешевы, причем живут в разных нишах — продукт от IBM, где-то на полпорядка дороже продукта от Microsoft. Так что далеко, не все считают оправданным их приобретение. Да и что говорить, в отличие от 90х годов, где в РФ доминировал («условно-бесплатный») стек разработки от Microsoft (великолепная для своего времени MVS6 — MVC6, MVB6 и т.п.) что соответственно определяло и выбор инструментов (SourceSafe и т.п.), сейчас огромное количество прекрасных бесплатных инструментов организации разработки.

Например, сердцем любого «уникального набора интегрированных систем поддержки разработки» является VCS — система контроля версий. Внутри TFS находится форк известной коммерческой VCS Perforce. Но сейчас появилось много классных централизованных и распределенных систем контроля версий, бесплатных и к тому же open-source, очень активно развивающихся. Недавно мы провели опрос об используемой VCS на центральном IT-портале, где ответило более двух тысяч человек и выяснилось, что коммерческими VCS (подсчет абсолютно по всем вендорам) пользуются менее 4% разработчиков, а в майнстриме среди централизованных VCS — Subversion, а среди распределенных VCS — Git.

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

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

TDD + DDD + MVP + GoF + PoEAA = Love!

Докладчик: Антон Бевзюк (Intel)

http://www.slideshare.net/Nfilippov/tdd-ddd-mvp-go-f-po-eaa-love

Наша команда имеет более чем 6-летний опыт использования гибких методологий.

За это время мы разработали десятки бизнес-приложений. Мы используем передовые практики (Scrum, XP, Kanban) и шаблоны (GoF, PoEAA), доказавшие свою эффективность.

Мы расскажем о том, как мы «поженили» все это разнообразие в одном финансовом приложении. Это приложение спроектировано по Domain-Driven Design (DDD), разработка ведется в строгом следовании парному программированию. Test-Driven Development (TDD) обеспечивает 100 %ное покрытие тестами бизнес-логики, а применение шаблонов MVP и Model-View-Viewmodel позволяет протестировать презентационную логику unit-тестами без применения внешних инструментов для тестирования интерфейса.

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

Отличительной особенностью нашего кода является то, что он вообще не содержит комментариев без ущерба для понимания. Код самодокументирующийся. Мы активно используем DSL для упрощения написания тестов. К настоящему моменту система содержит 4500+ тестов, которые выполняются не более 1 минуты.

Наш доклад раскрывает ряд best practices в области программной инженерии, например:

Автоматизированный деплоймент (на развертывание приложения уходит около 10 минут, делается это одним кликом).
Специализированные парные станции
Совместное использование всех практик XP (синергетический эффект)
Kaizen (постоянный пересмотр как процесса разработки, так и самого кода)
Элементы fun’а

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

Краткое резюме описываемого проекта в цифрах (в стиле заставки сериала «Numb3rs»:

2 года
12 разработчиков
50 человеко-лет (нет, вдумайтесь — это целая человеческая жизнь, по крайней мере, в разумном возрасте, среднего мужчины в РФ)
32 проекта в solution’е Visual Studio
3-хзвенная архитектура (WebForms/WinForms-клиент и MSSQL)
140000 строк
100000 из них — это строки 5000 тестов
20 экранных форм
10 Гб БД.

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

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

Из отзывов наших сотрудников:

С точки зрения архитектуры подход Intel’а отличается от книжного DDD, который описывал в своем докладе и Андрей Бибичев (например, если почитать тут ). Используя принцип Inversion of Control, они изолируют сборку с классами домена от инфраструктуры. Таким образом, домен у них не зависит ни от чего, и поэтому хорошо портируется, тестируется, и легко переносит существенные изменения инфраструктуры. Именно это, «чистый домен», они и ставят во главу угла своего подхода.

…Ребята также показались TDD-экстремистами, не знаю насколько это хорошо или плохо. Их мантры такие

Подумай->Напиши тест, который падает где ты ожидаешь -> Сделай минимальное исправление
Assert, по-хорошему, должен быть один, а исправление — минимальным. Если это не так, скорее всего нужен еще один тест.

… Все-таки они там TDD-маньяки и стремятся оттестировать все, что можно, и что нельзя. С тестированием «чистого домена» все более-менее просто, а дальше они начали тестировать GUI. По опыту прошлых проектов было известно, что ручное и скриптовое тестирование малоэффективно и мучительно. Поэтому они начали думать, как приспособить инструменты и методики unit-тестирования к тестированию GUI. Для этого они начали пересматривать архитектуру GUI-слоя (как неоднократно звучало, TDD — это не тесты, это методика проектирования!)

… Докладчики рассмотрели несколько паттернов устройства GUI (ModelViewController -> ModelViewPresenter -> ModelViewViewmodel). Собственно, смысл этого сводится к тому, чтобы сделать View единственной и максимально простой, зависящей от платформы частью паттерна, а все остальное — покрыть тестами.

… Я так понял, что этот подход позволил им достаточно безболезненно перевести клиента с WinForms на WebForms. С замечанием из зала о том, что для Web-интерфейса с активным использованием JavaScript’а на клиенте такой подход не работает, докладчикам пришлось, …, согласиться.

… Докладчики с гордостью заявляли, что стараются тестировать все, что может сломаться и с чем бывают проблемы: код, конфигурации, хранимые процедуры, даже связывание (binding) GUI. Любопытно, что в тестах они проповедуют принцип «1 тест — 1 assert». Мне не очень понятно, как это можно реально соблюдать, не впадая в безумное дублирование, и какой в этом смысл. Книжное «сразу понятно, что сломалось» смешно — нам почему-то и без этого принципа обычно понятно, что сломалось.

…Реализация DDD-подхода в данном случае состоит в том, что domain описан в отдельной сборке, которая является полностью независимой. Для обеспечения независимости используется прием Inversion-of-Control и одноименная библиотека.

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

…Действительно впечатляющие данные — 5000 тестов у них выполняются за минуту. Около 200 тестов, все-таки требующих наличия БД, у них выполняются минут за 10 и их запускают нечасто.

…Тесты, как известно, должны быть максимально простыми и выразительными. Поэтому они активно используют в тестах всякие практики типа FluentInterfaces, а также забавные методы-расширения, например, для задания дат в виде 11.12.of2009().

… При написании тестов использует свои embedded DSL. Например, вот такое:

var testDate = 11.12.of2009
 
public static class DoubleExtensions
{
    public DateTime of2009(this double date)
    {
        return new DateTime((int)date.Floor(), (int)(date-date.Floor())*100, 2009)
    }
 
}

…Много обсуждаемая в форумах по архитектуре (например, здесь) проблема — как отделять домен от инфраструктуры доступа к данным так, чтобы это было красиво и удобно. Они для этого активно используют паттерн Specification с возможностью сложных операций над спецификациями.

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

Кстати, повторимся, дискуссия о «правильном DDD» продолжилась и в онлайне. Присоединяйтесь к ней, если есть конструктивные замечания.

К сожалению, видео не совсем полное, мудак-оператор (я, Стас Фомин), куда-то задевал конец выступления. Сорри!

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Видеотека

2009-12-13T14:51:46Z

StasFomin: /* 2009-12-09 AgileDays-2009 */

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

~~Файлы размещаются на ресурсе narod.yandex.ru — очень быстрым для скачивания в рунете, порядка гигабайт за 10 минут.~~

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

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

Мы решили навести порядок и избавится от этой промежуточной страницы — теперь все ссылки на скачивание файла (обычно с narod.ru) размещаются под веб-версией видео (которое обычно на vimeo.com), на страницах соответствующих семинаров, докладов и прочих event-ов.

ShowTeamWork

2009-12-08T20:52:16Z

VitaliyFilippov:

Экстремальное программирование (встреча AgileRussia 2009-11-09)

2009-11-26T19:44:55Z

StasFomin:

9-го ноября в нашей компании прошло очередное собрание сообщества AgileRussia.ru, в этот раз была лекция Павла Афанасенко об Экстремальном Программировании (Extreme Programming), одной из концепций-прародителей всего Agile-движения.

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

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

Также прилагаем гибридное видео — видео из зала с обсуждением, параллельно с составлением майндмапа. Видео можно смотреть в вебе, а можно скачать.

Для желающих ненапряжно послушать обсуждение в «фоне», без «полного погружения» — прилагаем подкасты.

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

Deadline (Демарко)

2009-11-11T20:00:39Z

VitaliyFilippov: Массовая правка: замена Категория:Рецензии на Категория:Рецензии на книги, замена Category:Рецензии на Category:Рецензии на книги

Автор: Том ДеМарко (он же Том Де Марко)
Название: «Deadline. Роман об управлении проектами» (The Deadline: A Novel About Project Management')
Читать: http://www.litru.ru/?book=139

Одежка для Subversion - ViewVC и SVNSearcher

2009-11-05T15:13:17Z

BenderBot: 1 версия

Презентацию можно увидеть здесь.

MediaWiki

2009-11-03T18:47:08Z

VitaliyFilippov:

MediaWiki — Серверная вики-система, один из самых мощных вики-движков, написанный специально для Википедии и использующийся во многих других проектах. См. RuPedia:MediaWiki

Все вики-системы в нашей компании, включая CustisWiki, реализованы именно на этом движке.

Статья реплицируется в SMWiki, SBWiki, RDWiki, GZWiki, DPWiki, HRWiki, CBWiki, ORWiki, RAWiki, ITWiki, CRMWiki, NordeaWiki, EvolWiki, TMSWiki.

Репликация: База Знаний «Заказных Информ Систем» → «MediaWiki»

Статья реплицируется в Wiki4IntraNet.

Consolas в консоли

2009-11-02T19:07:19Z

BenderBot: 1 версия

Многим хороша командная строка (в Windows) — одно плохо, придется использовать уродливые raster-шрифты. Как для командной строки, так и для классных приложений с текстовым интерфейсом, типа Far.

По уму, надо бы иметь возможность выставлять для cmd или Far окна нормальные TrueType/Monospace шрифты, типа:

Consolas
DejaVu Sans Mono
подставьте ваш любимый monospace-шрифт.

Оказывается это можно, только нужно, как обычно сделать безумные магические пассы над реестром:

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont" /v 00 /d Consolas

и/или

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont" /v 000 /d "DejaVu Sans Mono"

Фишка в том, что таким образом можно создавать в очередной реестро-эрогенной зоне

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont

последовательность ключей «0», «00», «000», «0000» — куда забивать TrueType-monospace шрифты, которые тогда разрешать для выбора в консольных окнах.

Социально-психологические аспекты Agile (встреча AgileRussia 2009-10-19)

2009-10-26T12:31:17Z

StasFomin:

19 октября в компании Заказные ИнформСистемы прошло очередное собрание сообщества AgileRussia.ru, в этот раз была гуманитарная тема — «Социально-психологические аспекты Agile», а вел/модерировал встречу Сурен Самарчян, известный активной практикой внедрения Agile даже на уровень топ-менеджмента компаний.

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

Можете скачать его и руководствуясь им выделить интересные темы и написать полноценную статью.

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

Subversion

2009-10-26T08:23:48Z

StasFomin:

Subversion — свободная централизованная система управления версиями, созданная в 2000 г. компанией CollabNet Inc.

В 2007 году независимая компания Forrester Research, сравнивая преимущества и недостатки различных систем, оценила Subversion как «единоличного лидера в категории Standalone Software Configuration Management (SCM) и сильного участника в категории Software Configuration and Change Management (SCCM)».

В CustisWiki есть наши переводы статье идеологов этой системы, см. Категория:Статьи о Subversion.

JIRA

2009-10-25T20:13:56Z

AlexanderSokolov:

Atlassian JIRA (http://www.atlassian.com/software/jira/) — система чуть более широкая, чем только багтрекер, это Issue Tracking system — то есть система учета запросов как таковых. Система имеет веб-интерфейс, очень гибко настраивается под конкретный проект.

Distributed Version Control Systems: A Not-So-Quick Guide Through

2009-10-25T20:07:16Z

BenderBot: 1 версия

Перевод статьи «Distributed Version Control Systems: A Not-So-Quick Guide Through» от Sebastien Auvray с портала InfoQ.

Sébastien Auvray — senior software designer и энтузиаст технологий. Его заставляли использовать CVS и SVN, теперь он страдает на работе от ежедневного использования Perforce. Sébastien также один из редакторов InfoQ по теме Ruby.

К моменту перевода прошел уже год, и многие положения статьи изменились — самые очевидные исправлены переводчиком (Стас Фомин) (в частности, исправлены битые ссылки), часть снабжены сносками, указывающими на произошедшие изменения.

После выступления Линуса Торвальдса в Google в мае 2007, просвященного GIT, постоянно растет интерес и число пользователей распределенных систем контроля версий (Distributed Version Control Systems, DVCS).

Тут мы сначала сделаем краткое введение в понятия распределенного управления версиями, посмотрим, когда это стоит использовать, и почему, этом может быть лучше, чем то, что вы используете сейчас, и затем мы взглянем на трех ключевых игроков в этой области: git, Mercurial и Bazaar.

Алан Купер об интерфейсе. Основы проектирования взаимодействия

2009-10-12T20:09:32Z

VitalyKozlovtsev:

Автор: Алан Купер
Страница издательства: http://www.symbol.ru/date/638484.html
Рецензия: http://aboutface.gui.ru/

Психбольница в руках пациентов

2009-10-12T19:25:02Z

VitalyKozlovtsev:

«Психбольница в руках пациентов. Алан Купер об интерфейсах. Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие. Издание исправленное»

Автор: Алан Купер
Страница книги на сайте издательства: http://www.symbol.ru/novelty/666332.html
Рецензия: http://habrahabr.ru/blogs/books/19393/

Методы и алгоритмы вычислений на строках

2009-10-12T18:44:16Z

VitalyKozlovtsev:

Автор: Билл Смит
Страница издательства: http://www.williamspublishing.com/Books/5-8459-1081-1.html
Рецензия: http://www.rsdn.ru/res/book/prog/stringalgs.xml

Репликация: База Знаний «Заказных Информ Систем» → «Методы и алгоритмы вычислений на строках»

SconsDynamicallyAddTargetToExecutor

2009-10-08T18:55:07Z

StasFomin:

[svg]

Consider the following situation.

MainFile includes some GeneratedNN files (count of these files is unknown)
All these GeneratedNN files (+some other files) generated by one Generator file (for example, python script).
All included GeneratedNN files needed to be rescanned after generation (they can include other files).

I scan MainFile, and then I see inclusion of Generated1 file, I add something like this:

    cmd=env.Command(Generated1, Generator, RunMePlease)

But actually I need

    cmd=env.Command([Generated1,Generated2,…,GeneratedN], Generator, RunMePlease)

but I must add targets incrementally during MainFile scan…

So the question is: How to dynamically add targets to Command? I try something like

Generator.executor.targets.append(env.fs.Entry(GeneratedN))

but it seems not working…

Agile-metrics-for-business

2009-09-17T17:15:35Z

VitaliyFilippov:

[на всё окно][свернуть]

FeedOnFeeds

2009-09-16T12:21:07Z

VitaliyFilippov:

FeedOnFeeds («Лента Лент») — серверный многопользовательский RSS и Atom -агрегатор (веб-приложение).

Оригинальная версия мертва. Есть пара живых «форков» — наш и RomanSixty. В нашем форке упор на производительность + мелкие новые фичи, у RomanSixty из фич есть адаптивный расчёт времени обновления.

Репозиторий нашего форка: https://github.com/vitalif/FeedOnFeeds либо http://yourcmc.ru/git/summary/FeedOnFeeds.git
Сайт старой версии: http://www.feedonfeeds.com/
Язык разработки: PHP
Распространение: copyleft, opensource (лицензия GPL).

SuperGenPass

2009-09-10T14:34:31Z

VitaliyFilippov:

«Полное и окончательное решение проблемы паролей в Интернет»

Project Metrics for Software Development

2009-09-05T16:06:21Z

BenderBot: 1 версия

Перевод статьи http://www.infoq.com/articles/project-metrics

Автор: Carlos Sirias.
Перевод: Стас Фомин.

AgileEVM: Measuring Cost Efficiency Across the Product Lifecycle

2009-08-28T15:45:07Z

BenderBot: 1 версия

http://www.infoq.com/articles/agile-evm

Автор: Tamara Sulaiman

Tamara Sulaiman — консультант по управлению в компании SolutionsIQ, специализирующаяся на тренингах по переходу на SCRUM команды и организаций. У Тамары более 15 лет опыта в бизнес-управлении и разработке ПО. Она Certified Scrum Trainer (CST) и Project Management Professional (PMP).

AgileEVM — это некоторая адаптация традиционной практики управления проектами, заключающейся в измерении и сверке текущих значений:

общих затрат (integrated cost);
сроков (schedule);
объема функционала (scope);

с первоначальным планом (baseline plan), используя метрики «Управления Освоенными Объемами» (Earned Value Management, EVM).

Эти методы измерений были модифицированы, чтобы с легкостью вписаться в рамки SCRUM-практик управления проектами. AgileEVM можно использовать для измерения эффективности затрат совместно с традиционными EVM-метриками в течении всего жизненного цикла продукта. Это существенно дополнит Agile-управление на протяжении всего жизненного цикла продукта, заранее предупреждая о нездоровых тенденциях.

Так как «AgileEVM» использует те же метрики, что и традиционные EVM-техники управления освоенными объемами, их обоих можно сочетать, получая комбинированную методологию, дающую результаты на более высоком уровне.

Например, «освоенные объемы», полученные из какого-нибудь Agile-проекта, можно скомбинировать с таковыми, вычисленными для традиционно-планового проекта, или даже портфеля проектов, и получить таким образом общие «освоенные объемы» (earned value).

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

Agile Modeling with Mind Map and UML

2009-08-17T18:44:16Z

BenderBot: 1 версия

Перевод статьи Agile Modeling with Mind Map and UML.

SVNSearcher

2009-07-30T12:38:44Z

VitaliyFilippov: /* Примечания */

SVNSearcher — система полнотекстового поиска по содержимому Subversion-репозиториев, в том числе, и по старым ревизиям файлов. Поддерживает (с минимальными телодвижениями) русскоязычную морфологию и офисные форматы документов, а также разграничение прав доступа к файлам.

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

Для поиска по SVN и CVS репозиториям мы рекомендуем нашу сборку ViewVC вкупе с Apache Tika и поисковым сервером Sphinx.

Сайт: http://svn-search.sourceforge.net/
Распространение: свободная, с открытым исходным кодом^[1].

↑ Единственное упоминание о лицензии на сайте SVN-Searcher — «You can download, use and develope the project according to OpenSource licence». Будем считать, что имеется ввиду according to any OpenSource license.

WikiHelper

2009-07-16T14:54:30Z

BenderBot: 1 версия

WikiHelper — расширение для браузера Mozilla Firefox, позволяющее редактировать файлы из MediaWiki во внешних программах, например, SVG формата — в Inkscape.

Последняя доступная на данный момент версия — 1.0.218 (218 — по номеру последней ревизии Subversion, в которой менялся код). Тестировалась с Firefox/Iceweasel версий 3.0.11 и 3.5, теоретически, должна работать и с более новыми, и с более старыми.

Programmer Insecurity

2009-06-30T21:16:11Z

BenderBot: 1 версия

Programmer Insecurity/Комплексы Программиста

Перевод статьи «Programmer Insecurity/Комплексы Программиста» ^[1], выполнен сообществом компании «Заказные ИнформСистемы».

Я хотел бы о многом сегодня поговорить. Поговорить о том, что я никогда прежде не замечал, хотя вероятно, должен был заметить.

Всегда был стереотип, что программисты асоциальны:

 Q: How do you know when an engineer is outgoing?
 A: He looks at your shoes!

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

Мой приятель Фитц и я долго проповедовали о best practices в разработке приложений с открытым исходным кодом — когда человек должен быть открытым и честным с работой другого, воспринимать разбор своего кода и уметь конструктивно критиковать, и, главное, активно общаться с коллегами.

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

У кого есть время, чтобы отрецензировать тысячи строк кода? А что, если там были неправильные архитектурные решения с самого начала? Есть ли теперь смысл указывать на это?

Сбрасывание такой «кодовой-бомбы» в сообщество, редко когда идет проекту на пользу: команда либо должна либо полностью отклонить ее, либо принять и иметь дело с гигантским мутным BLOB-ом, который трудно и понять, и править, и поддерживать. К тому же, это явно двигает проект в некотором направлении без всяких обсуждений или консенсусных решений.

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

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

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

Похоже, они охотно делятся кодом, только когда могут показать, что они «непогрешимы». Хотя, возможно это в природе человека.

Оцените несколько историй, которые я собрал:

Просьбы на конференции «Google I/O»

 Пару недель назад, когда моя команда была на конференции «Google I/O»,
 мы поставили демонстрационный стенд, посвященный сервису поддержки проектов с открытыми исходными кодами.
 Раз за разом, мы получали просьбы типа:

«Ребят, вы можете заставить Subversion в Google Code возможность прятать определенные ветки?»
«Парни, а можно создавать открытые проекты поначалу скрытые от мира, а потом раскрыть их, когда они будут готовы?»

По сути, они говорили одно и то же: «Я не хочу, чтобы люди видели процесс моей работы, пока она не стала идеальной»

Просьбы в список рассылки Google Code

Почистить так или иначе svn-репозиторий на Google Code. Встречаются и разумные причины — например, случайный коммит секретных данных, или необходимость загрузить полностью историю из другого SVN-репозитория.

Но в основном, мы получаем некорректные (да, мы их отклоняем) просьбы вроде «Привет, я хочу переписать свой код с самого начала. Вы могли бы уничтожить историю?». Это значит «Я не хочу, чтобы люди увидели мой старый код, мне так за него стыдно!»

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

Код-ревью воспринимаются как личные нападения

Фитц рассказал смешной анекдот о своем друге, который перешел из мира open-source в корпоративную разработку. Перескажу своими словами:

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

Мораль: рецензии кода далеки от стандартной практики в корпоративном сообществе, более того, большинство программистов не способны отделить свои хрупкие «Я» от кода, который они пишут.

Повторяйте за мной: ты это не твой код!

Использовать распределенный контоль версий — быть в пещере

Один мой друг работает над несколькими проектами, в которых используют git и mercurial. Недавно он рассказал мне следующую историю.

В основном, он работал с двумя командами над проектом.

Одна команда часто публиковала изменения… «… в результате у меня была возможность постоянно просматривать их проект в течении семестра, регулярно предлагая улучшения дизайна и предоставляя рецензии на код… …В результате этого [их проект] развивается на полном ходу и практически функционирует.

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

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

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

Я не знаю, боялись ли они опубликовать это, или только не заботились об этом. Но так или иначе, учитывая код, что я видел, практический результат составляет 5 потраченных впустую месяцев.»

Прежде, чем Вы начнете возражать — да да, я знаю, что потенциально cave-hiding («разработка в тайной пещере») и написание кодовых бомб возможно и с использованием централизованной системой управления версиями, такой, как Subversion.

Но у моего друга есть интересная точка зрения:

Я думаю, что этот недостаток имеет место по крайней мере частично из-за того, что DVCS даёт легкий способ обнести себя стеной и забраться в пещеру. Если бы мы использовали svn, я думаю, что «пещерный» барьер был бы слишком высок, и я сразу бы увидел этот код.

Другими словами, да, это было бы в основном социальной проблемой. Команда запуталась в распределении кода.

Но, так как они использовали распределенное управление версиями, у них возникла видимость ложной безопасности.

«Смотрите, мы коммитим изменения в наш репозиторий каждый день … прогресс!»

Если бы они использовали Subversion, то гораздо менее вероятно, что они сидели бы над патчем из 5000 строк в их рабочей копии в течение 5 месяцев; они должны были бы показать работу намного раньше.

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

Это было моей главной темой ранее, когда я написал о рисках распределенного управления версиеями.

Хорошо, так, каково заключение? — Просто очевидно, что люди боятся показывать незаконченную работу.

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

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

Вот классическая «рекомендация» для системы вроде git (взято из комментария в блоге): «Не надо говорить мне, что я должен сотрудничать с другими людьми в начале и публиковать мои изменения как можно раньше. Я сотрудничаю с другими людьми, но иногда хочу делать определенную часть работы в одиночку.»

Хм, ладно! Только не работай в одиночку слишком долго!

Немного отступая от основной темы, скажу почему я предпочитаю Mercurial Git-у, проделав некоторые исследования и прочитав немного об этих системах.

Git гораздо более склонен к «пещерности», а я этого не люблю.

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

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

Другими словами, git по умолчанию считает, что вся работа «пещерная», и с радостью уничтожает историю. Mercurial же по умолчанию разделяет все, и не может стирать историю.

Я знаю, этот пост получился очень длинным, но дайте мне еще постоять на трибуне из ящика из-под мыла:

Будьте ясными.
Постоянно публикуйте свою работу.
Приветствуйте обратную связь.
Воспринимайте критику.
Дайте возможность другим людям найти ваши ошибки.
Ваш код — это не вы сами.
Не бойтесь ежедневных ошибок — учитесь на них (Как говорят в Google, «не беги от ошибки — ошибайся часто, быстро, и учись!»).
Храни всю свою историю, и удачи, и ошибки.

Все эти приемы — путь совершенствования в программировании. Если вы не следуете им, вы обманываете свое собственное развитие.

Уф-ф! Теперь я чувствую себя лучше.

↑ http://blog.red-bean.com/sussman/?p=96

Subversion или CVS, Bazaar или Mercurial

2009-05-08T16:50:22Z

BenderBot: 1 версия

Перевод статьи «Subversion or CVS, Bazaar or Mercurial» ^[1], выполнен сообществом компании «Заказные ИнформСистемы».

↑ John Ferguson Smart, JavaWorld.com, 09/18/07, http://www.javaworld.com/javaworld/jw-09-2007/jw-09-versioncontrol.html

Линус Торвальдс о GIT на Google Talks

2009-05-03T01:53:07Z

BenderBot: 1 версия

Перевод доклада Линуса Торвальдса о системе контроля версий git на «Google Talk» ^[1], выполнен сообществом компании «Заказные ИнформСистемы».

↑ Оригинальное видео доклада http://www.youtube.com/watch?v=4XpnKHJAok8

Darwin Information Typing Architecture

2009-04-06T15:53:20Z

BenderBot: 1 версия

Darwin Information Typing Architecture (DITA) — способ написание технической документации на основе XML разработанный в компании IBM. Данная статья написана в результате исследования технологии DITA, как возможного стандарта документирования в компании.

Используется в компаниях:

IBM
Oracle
Adobe
Autodesk
EMC
Nokia
McAfee, Inc.
Sybase, Inc.
и другими, полный список тут http://dita.xml.org/deployments
так же используется для документирования в проекте Apache Derby (база данных)
существует ряд коммерческих CMS систем поддерживающих DITA

Основные преимущества:

ориентация на темы при написании текста;
ориентация на повторное использование текста;
специализация;
обработка на основе свойств;
использование существующих тегов и инструментов.

Основные свойства:

основана на плоской XML-разметке;
поддерживает произвольные теги разметки;
возможность преобразования в форматы:
- wordrtf
- pdf
- html
- xhtml
- eclipsehelp
- eclipsecontent
- javahelp
- htmlhelp
- xml docbook
- troff

ViewVC

2009-03-27T09:57:18Z

VitaliyFilippov:

ViewVC — система онлайн-просмотра репозиториев систем версионного контроля CVS и Subversion. Ранее называлась ViewCVS.

Сайт: http://www.viewvc.org/, http://viewvc.tigris.org/
Лицензия: Permissive, типа MIT. Free & OpenSource.
Версия с нашими доработками (ViewVC4Intranet): https://github.com/vitalif/viewvc-4intranet
Ниже значком () помечены фичи, присутствующие только в нашей версии.

Оперативное хранилище в АБС – два в одном

2008-09-19T16:27:25Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».
Андрей Таранов, аналитик ООО «Заказные ИнформСистемы».

«Оперативное хранилище в АБС – два в одном»^[1]

Летом 2003 года в Интернете проходила дискуссия экспертов-представителей банков и фирм-разработчиков банковских систем, под названием «Хранилища данных. Для чего они нужны банкам?» (интересующихся подробностями отошлем на сайт).

Мнение одного из участников (А.В. Погудина, руководителя банковского направления компании «ЦФТ») на наш взгляд очень точно описывает существующую ситуацию. Позволим себе процитировать:

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

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

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

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

К созданию подобного оперативного хранилища (аналитической АБС) нас привел детальный анализ бизнес-задач клиента, показавший, что аналитические данные регулярно используются в процессе оперативного управления. И мы предположили, что аналитическое хранилище не обязательно должно быть физически отделено от OLTP-системы. Более того, хранилище может быть погружено в OLTP-систему и фактически составлять ее базовый компонент. Именно такой вариант реализован в нашей банковской системе GROSS (с сентября 2004 г. CustIS Bank), базирующейся на учетно-аналитическом ядре CustIS Accounting® (одна из торговых марок компании «Заказные ИнформСистемы»).

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

↑ «Банковские технологии», №7-8.2003, стр. 56-59.

Промышленная биллинговая система в ЖКХ г. Курчатова

2008-09-19T16:11:08Z

BenderBot: 1 версия

Автор

Михаил Татаренков, руководитель направления «Радей» компании «Заказные ИнформСистемы».
«Промышленная биллинговая система в ЖКХ г. Курчатова»^[1]

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

Так в 2006 году в ЕИРКЦ г. Курчатова был инициирован проект внедрения программно-технологического комплекса «Радей», созданного московской компанией «Заказные ИнформСистемы». С декабря 2006 г. по июль 2007 г. система работала в режиме опытно-промышленной эксплуатации. В июле 2007 г. программно-технологический комплекс (ПТК) «Радей» (www.radey.ru) был сдан в промышленную эксплуатацию. За 6 месяцев в городе с населением более 40 тысяч человек была полностью модернизирована единая общегородская система расчета, приема и учета платежей за жилищно-коммунальные услуги. Нельзя сказать, что обошлось совсем без трудностей. Как это случается практически во всех проектах модернизации РЦ, особые усилия потребовались в ходе внедрения — при выверке и переносе данных в новую систему.

Сейчас программный комплекс «Радей» успешно установлен на сервере в «Едином информационно-расчетном кассовом центре (ЕИРКЦ) г. Курчатова». Он обслуживает пять абонентских пунктов, расположенных в разных частях города. Абонентские пункты взаимодействуют с расчетным центром в режиме on-line. В любом из абонентских пунктов жители города могут оплатить жилищно-коммунальные услуги, получить разъяснения по начислениям и принципам расчета, зарегистрировать изменения на лицевом счете. Каждый пункт оснащен современным оборудованием, которое существенно повысило эффективность работы персонала и увеличило скорость обслуживания населения. Это позволило избавиться от очередей без потери качества обслуживания.

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

В состав единой квитанции, ежемесячно выставляемой населению г. Курчатова, вошли начисления:

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

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

В результате внедрения ПТК «Радей» ЕИРКЦ г. Курчатова получил современную систему автоматизации расчетов и начислений, которая способна оперативно настраиваться под изменения жилищного законодательства. Новый программный комплекс не только заменил собою устаревшее ПО, но также значительно расширил возможности ЕИРКЦ. Экономический эффект от внедрения проявился быстро: уже в первые месяцы эксплуатации системы сбор денежных средств от населения превысил 100%, поскольку жители стали оплачивать не только текущие начисления, но и свои долги по ЖКХ.

Причем, все денежные средства, полученные от населения в уплату за ЖКУ, оперативно направляются МУП «ЕИРКЦ» непосредственно поставщикам ЖКУ в строгом соответствии с договорными обязательствами и объемами оплаты. За счет этого обеспечивается максимально эффективное функционирование городского жилищно-коммунального комплекса в части информационных и финансовых потоков.

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

Не останавливаясь на достигнутом, МУП «ЕИРКЦ» планирует в 2008 году установить у поставщиков жилищно-коммунальных услуг и управляющих компаний (по их желанию) выносные терминалы, обеспечивающие им оперативный доступ к информации о начислении и оплате по предоставленным услугам.

Также в 2008 году МУП «ЕИРКЦ» планирует запустить собственный сайт, обратившись к которому, посетители смогут:

получить общие сведения о деятельности расчетно-кассового центра, узнать режим работы, адреса и контактные номера телефонов отделений МУП «ЕИРКЦ»;
просмотреть информацию по лицевым счетам за жилищно-коммунальные и иные услуги, понять, как формируется оплата за ЖКУ, а также с внедрением системы виртуальной оплаты оплатить свои счета в режиме он-лайн;
узнать о ценах, тарифах и услугах;
ознакомиться с нормативными документами, федеральным, региональным и муниципальным законодательством, согласно которому происходит начисление оплаты за ЖКУ;
узнать о льготах и субсидиях на оплату за ЖКУ;
просмотреть информацию о плановых ремонтах и отключениях в своем доме.

В дальнейшей перспективе МУП «ЕИРКЦ» — обеспечить возможность оплаты гражданами счетов за ЖКУ в режиме он-лайн непосредственно со своего персонального компьютера.

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

↑ Журнал «Коммунальный комплекс Подмосковья», №1 (февраль) 2008.

Парадоксы развития информационных систем: количественный подход

2008-09-19T16:11:03Z

BenderBot: 1 версия

Автор: Елена Сомина, начальник управления банковских технологий ООО «Заказные ИнформСистемы».

«Парадоксы развития информационных систем: количественный подход»^[1]

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

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

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

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

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

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

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

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

Подробный анализ изменения метаданных мы провели на примере нашей банковской системы CustIS Bank, которая 5 лет функционирует в небольшом стабильно работающем банке, который нельзя отнести к быстро развивающимся. На основании информации о создании, изменении, удалении метаданных за все годы эксплуатации АБС были построены графики зависимости количества модифицированных метаданных от времени. На рис.1 мы можем наблюдать заметную динамику их эволюции.

Рисунок 1.

Точка А₀ — старт «операционного дня» в новой АБС. Первые 8 месяцев длилось развертывание системы, внедрение и адаптация — график демонстрирует увеличение количества метаданных почти в 4 раза. После этого (частки B и С) началось экстенсивное развитие АБС. За 4 года штатной эксплуатации и сопровождения количество созданных метаданных по отношению к точке А₁ составило 85%, а с учетом правок уже существующих метаданных изменения достигли 164%.

В итоге — примерно 40%-е среднегодовое изменение наполнения системы метаданных, отражающее динамику развития бизнес-процессов в банке за период «стационарной» эксплуатации (данные в точке А₂ по отношению к точке А₁). Причем вне этого графика остались изменения программного кода (которые уменьшаются по мере развития системы, поскольку в нашей технологии кодирование формирует «стабильный» фундамент системы), а также изменения интерфейсных форм и внешней отчетности для ЦБ РФ.

Для иллюстрации содержания изменений в АБС рассмотрим участок С — это «бурный» 2004 год. На рис.2 в увеличенном масштабе видны скачки в объемах метаданных, связанные с изменениями требований ЦБ РФ и федеральных законов (валютное законодательство, финансовый контроль). На этот же период пришлась перестройка работы внутри банка, реорганизация, повлекшая изменение бизнес-процессов и документооборота.

Рисунок 2.

Мировой опыт показывает, что динамика изменений требований заказчика при развитии программной системы достигает 2-10% в месяц в период интенсивной разработки и уменьшается на этапе стационарного развития. В приведенном нами примере на эксплуатационном этапе функционирования АБС средняя скорость изменения составила примерно 3.5% в месяц. Поскольку параметры нашего проекта вполне уложились в мировую статистику, мы можем надеяться, что не ошиблись с выбором единицы измерения сложности системы.

↑ «Банки и технологии», №1-2005, стр 24-28.

Современная IТ-стратегия для динамичного банка — исполнение по заказу

2008-09-19T16:10:57Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».

«Современная IТ-стратегия для динамичного банка — исполнение по заказу»^[1]

Заголовок статьи может удивить читателя, привыкшего к тому, что в течение последних лет ему настойчиво предлагают покупать тиражные разработки автоматизированных банковских систем (АБС), да и выбирать сейчас действительно есть из чего. Правда, выбор этот нелегок. Почитав рекламные материалы и поговорив с персоналом фирм-разработчиков, Вы заметите, что на первый взгляд все предлагаемые продукты очень похожи: все «идут от документа», все «работают в технологии клиент-сервер», практически все уже работают на промышленной СУБД и т. д. Да и предлагаемый набор банковских функций практически один и тот же: во всех системах есть все, что нужно, и даже больше того. Однако при более внимательном рассмотрении обнаруживается, что под терминами «клиент-сервер», «документы» и даже «технологии Oracle» понимаются достаточно разные вещи. При детальном изучении функционала, Вы нередко убеждаетесь, что предлагаемая система не полностью отвечает (или полностью не отвечает) потребностям Вашего банка. Естественно, встает вопрос о доработке продукта конкретно для Вас, и бойтесь тех, кто скажет, что это дешево.

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

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

↑ «Банки и технологии», № 4-2003, стр. 32-36.

Экономичная стратегия проектов по заказной разработке

2008-09-19T16:10:51Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».

«Экономичная стратегия проектов по заказной разработке»^[1]

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

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

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

Рис.1. «Рычаг» проекта по Д. Майстеру

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

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

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

Понятие «рычага» — ключевое для анализа экономики проектов и, соответственно, управление разными типами проектов и ценообразование в них совершенно различны.

↑ Журнал Intelligent Enterprise (Корпоративные системы),№ 20, 31 октября 2005, стр.40-43.

Какой расчетный сервис нужен поставщикам ЖКУ

2008-09-19T16:10:46Z

Пресс-служба: переименовал «Какой расчетный сервис нужен поставщикам ЖКХ» в «Какой расчетный сервис нужен поставщикам ЖКУ»

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».

«Какой расчетный сервис нужен поставщикам ЖКХ»^[1]

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

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

Эти тенденции заключаются в настойчивом стремлении поставщиков услуг и ресурсов к созданию или развитию собственных абонентских служб. Более того, крупные поставщики и управляющие компании строят вполне серьезные планы по созданию собственных расчетных центров. Предполагается, что эти новые расчетные центры придут на смену существующим муниципальным ВЦ/РКЦ, а те, в свою очередь, «отомрут», как уже «отмирают» во многих городах муниципальные поставщики ЖКУ.

Рассмотрим некоторые аспекты, которые, на наш взгляд, определяют перспективы взаимоотношений поставщиков и управляющих компаний с расчетно-кассовыми центрами (РКЦ):

влияние на деятельность поставщиков и управляющих компаний начавшегося процесса коммерциализации ЖКХ;
взаимоотношения РКЦ и собственных сбытовых компаний поставщиков;
риски поставщиков при организации сбыта их услуг через РКЦ.

В настоящее время в ЖКХ выбор сфер деятельности достаточно прибыльных, интересных с точки зрения частного бизнеса, весьма ограничен: это сетевые компании электроэнергетики вместе с предприятиями энергосбыта, а также управляющие компании по обслуживанию жилого фонда. Остальные сферы зачастую не являются достаточно привлекательными из-за тарифного дисбаланса и высоких рисков.

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

↑ Ежемесячный журнал руководителя и главного бухгалтера «ЖКХ», № 11, ноябрь 2005, стр. 73-78.

Биллинговая система в большом городе

2008-09-19T16:10:41Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».

«Биллинговая система в большом городе»^[1]

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

↑ Ежемесячный журнал руководителя и главного бухгалтера «ЖКХ» № 1, январь 2005, стр. 73-78.

Многие тиражные продукты начинаются как заказные разработки

2008-09-19T16:10:35Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».

«Многие тиражные продукты начинаются как заказные разработки» ^[1]

Как бы вы охарактеризовали ключевые отличия заказного ПО от тиражного?

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

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

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

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

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

Можно ли, на ваш взгляд, сравнить заказные и тиражные системы по характеристикам жизненного цикла?

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

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

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

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

Насколько сложнее, из вашей практики, стоятся отношения с заказчиком при разработке на заказ? Какие ключевые риски связаны с подобными проектами?

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

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

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

Если оставить в стороне случаи саботажа или головокружения от успехов, то следует обозначить основную, фундаментальную причину сложностей комплексной автоматизации предприятия. Индустрия информационных технологий все же относительно молода. И если с подготовкой ИT-специалистов в наших вузах все обстоит далеко не блестящим образом, то в плане преподавания информатизации экономическое и бизнес-образование делают только самые начальные шаги. Хотя классики, вроде Фреда Брукса, еще в 70-е годы описали особенности создания программных решений в терминах инженерных систем, многие управленцы не допускают мысли о том, что корпоративная система — это такое же сложное техническое сооружение, как, например, современное офисное здание.

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

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

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

Как, из вашей практики, решаются вопросы сопровождения в рамках заказных проектов?

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

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

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

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

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

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

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

Какие направления разработки являются сегодня для вас приоритетными?

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

В малотиражных решениях приоритет принадлежит коммунальному биллингу (система «Радей»), автоматизации социальной защиты населения (система «Радей-Соцзащита»), а также новому решению для финансовых компаний — CustIS General Ledger, XML edition.

Каковы ваши планы по развитию бизнеса в ближайшие годы?

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

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

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

↑ Обзор-интервью на сайте CNews («Рынок корпоративного ПО-2005»).

Вне тиража

2008-09-19T16:10:29Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы» (CustIS).: Текст интервью Владимира Рахтеенко в материале Елены Некрасовой «Вне тиража»; Публикация в журнале CIO (Chief Information Officer), № 8, 21 августа 2006, стр. 143^[1]

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

На наш взгляд, следует различать три типа решений: внутренние разработки, тиражные и заказные.

Внутренняя разработка — это разработка силами ИТ-специалистов внутри организации.

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

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

[svg]

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

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

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

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

Гибкость архитектуры и возможность масштабирования при изменении бизнес-процессов не свойственны ПО собственной разработки, несмотря на то, что руководители зачастую убеждены в обратном. Бытует мнение, что «если своим прикажем — все сделают». Однако в реальности бессистемное развитие решений рано или поздно достигает своего предела. Для тиражных решений архитектурная гибкость может быть обеспечена только отчасти. Ее относительно несложно добиться для количественных, линейных характеристик в рамках заданной отраслевой модели, но гораздо труднее — для масштабирования логики бизнеса.

[svg]

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

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

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

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

↑ Журнал CIO (Chief Information Officer), № 8, 21 августа 2006, стр. 143, «Вне тиража».

Заплатить за квартиру в Саратове? Легко!

2008-09-19T16:09:08Z

BenderBot: 1 версия

Татьяна Богатова, Начальник финансового отдела Министерства по строительству и ЖКХ Саратовской области:

«Заплатить за квартиру в Саратове? Легко!»^[1]

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

(Из выступления участника саратовского семинара):

Сегодня куда ни бросишь взгляд — он обязательно уткнется в реформирование и преобразование. Реформа образования, вооруженных сил, ветеранских льгот, административная реформа, пару лет назад ко всему этому прибавилось еще и жилищно-коммунальное хозяйство (ЖКХ). «Следует констатировать, что реформа ЖКХ в масштабах страны идет слабо» — этими словами открыл межрегиональный семинар коммунальщиков мэр Саратова Юрий Аксененко. Однако главным замыслом семинара была вовсе не констатация этого печального факта, а презентация интересного саратовского опыта по организации Единого расчетно-кассового центра (ЕРКЦ) для оплаты коммунальных услуг в городе с почти миллионным населением.

↑ «PC Week/RE», № 26-2004, 20 июля 2004.

Комплекс мер по реализации социальной поддержки населения

2008-09-19T16:09:04Z

BenderBot: 1 версия

Автор: Новикова Лариса Николаевна, Начальник финансового отдела Министерства по строительству и ЖКХ Саратовской области.

«Комплекс мер по реализации социальной поддержки населения»^[1]

Современная стратегия реформы ЖКХ определена подпрограммой «Реформирование и модернизация ЖКХ Российской Федерации» ФЦП «Жилище». В ней перечислены основные подходы и экономические принципы необходимых в этом секторе преобразований.

Сегодня жилищная политика меняет свое направление: от прямых бюджетных дотаций организациям ЖКХ переходит к предоставлению адресных субсидий непосредственно гражданам, отказу от установления убыточных цен и тарифов, не обеспечивающих полного возмещения организациям ЖКХ стоимости предоставленных услуг. Особое внимание в ходе проведения мероприятий по реформированию ЖКХ уделяется государственной социальной поддержке малообеспеченных категорий населения, предоставляемой в форме адресных субсидий при оплате жилищно-коммунальных услуг.

Для отработки нового механизма предоставления гражданам адресной целевой социальной помощи в Российской Федерации в 2002-2003 гг. проведен соответствующий эксперимент при оплате жилищно-коммунальных услуг с использованием персонифицированных социальных счетов. В проведении эксперимента приняло участие 19 субъектов Российской Федерации, в том числе и Саратовская область. На территории Саратовской области эксперимент проводился в Балаковском, Балашовском, Марксовском и Энгельсском муниципальных образованиях, в 2004 г. — в Новобурасском муниципальном образовании.

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

С целью перехода на систему адресного предоставления субсидий в г. Саратове ЕРКЦ г. Саратова совместно с Комитетом по труду и социальному развитию администрации города проводят совместную работу по созданию единого информационного пространства^[2]

Внедрение этой системы также поможет:

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

Установление единого информационного пространства для ЕРКЦ г. Саратова и Комитетом по труду и социальному развитию администрации города является практическим шагом по формированию областной информационной системы по учету плательщиков ЖКУ, первый этап которой — создание базы данных получателей адресной социальной помощи. Конечная реализация этой задачи позволит обеспечить открытый доступ к новой, объективной и актуализированной информации, необходимой для принятия корректных решений органами государственной власти и местного самоуправления, а также всеми субъектами хозяйственной деятельности в области ЖКХ, социальной сферы, экономики.

В настоящее время на территории региона проводится централизованная работа по созданию программного обеспечения, формированию единой базы данных получателей адресной помощи и оборудованию техническими средствами служб субсидий^[3].

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

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

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

Суть модели «единое социальное окно» заключается в организации пунктов первичного приема граждан — филиалов ЕРКЦ — для оказания централизованной социальной помощи населению по месту жительства с ведением баз данных по людям, семьям, домохозяйствам, льготам, субсидиям и т. п.

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

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

Органы местного самоуправления могут:

получать полную информацию о заявителе, в том числе о положенных ему видах социальной помощи;
передавать данную информацию органам социальной поддержки — для назначений городского социального пособия, отделам субсидий — для установления субсидии на оплату жилья и коммунальных услуг;
оценивать стоимость полного пакета социальных выплат и льгот, предоставляемых из местного бюджета и бюджетов других уровней как в расчете на каждого жителя, так и по муниципальному образованию и субъекту Российской Федерации в целом;
разрабатывать те или иные социальные программы с учетом анализа социально-экономического положения жителей города, основанного на информации единой базы данных.

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

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

↑ Ежемесячный журнал руководителя и главного бухгалтера «ЖКХ», №10, ноябрь 2005, стр. 12-13.
↑ Проект автоматизации для КТСР г. Саратова.
↑ Начат проект автоматизации для ЖКХ Саратовской области на базе «Радей-Соцзащита»

О правах ЕРКЦ

2008-09-19T16:09:02Z

BenderBot: 1 версия

Автор

Татьяна Лисина, ведущий аналитик ООО «Заказные ИнформСистемы».
«О правах ЕРКЦ»^[1]

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

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

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

↑ «Коммунальный комплекс России», №2 (февраль) 2005, стр.20-21.

Единые информационные расчетные центры как инфраструктурное обеспечение реформы жилищно-коммунального хозяйства

2008-09-19T16:09:00Z

BenderBot: 1 версия

Автор

Татьяна Лисина, к.ф.-м.н., главный эксперт ООО «Заказные ИнформСистемы».
«Единые информационные расчетные центры как инфраструктурное обеспечение реформы жилищно-коммунального хозяйства»^[1]

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

В условиях облегченного (по сравнению с другими капиталоемкими отраслями хозяйства) входа на формирующийся рынок товаров и услуг, обеспечивающих работу ЖКХ, возросла конкуренция между игроками, особенно агрессивная на рынке платежных услуг. К счастью, сегодня в России уже никто не верит, что рынок сам по себе все отрегулирует, поэтому муниципальные органы власти пытаются активно влиять на ситуацию в ЖКХ. Для этого надо знать, все ли в порядке с расчетами и платежами за жилищные и коммунальные услуги на территории муниципалитета. Естественно, что у муниципальных властей возникает вопрос о законности и эффективности работы единых информационных расчетных (или расчетно-кассовых) центров (далее для краткости будем называть их ЕИРЦ).

В отличие от чисто платежных систем основные функции ЕИРЦ составляют полный биллинговый цикл:

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

Рисунок. Основные функции единых информационных расчетных центров

Надо сказать, что расчет квартплаты специалистами вычислительных центров существовал еще с советских времен. Так, например, в городе Туле гордятся тем, что областной «ИВЦ ЖКХ» создан в 1988 г. на базе Кустовой машинно-счетной станции, а первые шаги механизации учета в жилищно-коммунальном хозяйстве Тульской области были сделаны в далеком 1967 г. на основе счетно-клавишной техники. В массовом порядке центры по расчету оплаты за жилищно-коммунальные услуги стали создаваться в форме муниципальных унитарных предприятий или муниципальных учреждений с 2000 г. в соответствии с Постановлением правительства РФ от 3 августа 1999 г. № 887 «О совершенствовании системы оплаты жилья и коммунальных услуг и мерах по социальной защите населения». В связи с этим аргументы сторонников использования ЕИРЦ основаны на опыте многолетней работы (самые существенные из них приведены в таблице). В зависимости от того, какие проблемы в муниципалитете наиболее злободневны на момент принятия решения о схеме организации работы с оплатой за ЖКУ, любой из перечисленных доводов может стать решающим.

Таблица. Аргументы в пользу централизованного биллинга

Более подробно выгоды и преимущества для всех заинтересованных сторон описаны в статье Андрея Борейко^[2].

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

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

Попробуем оценить эти положения.

↑ «Имущественные отношения в РФ», №11 (ноябрь) 2007, стр.3-9.
↑ Борейко А.А. На стыке интересов // ЖКХ. 2005. № 7.

Проблемы исполнения на местах Правил предоставления коммунальных услуг гражданам

2008-09-19T16:08:56Z

BenderBot: 1 версия

Татьяна Лисина, к.ф.-м.н., ведущий аналитик ООО «Заказные ИнформСистемы»

«Проблемы исполнения на местах Правил предоставления коммунальных услуг гражданам»^[1]

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

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

Для решения этой задачи 23 мая 2006 года вышло постановление Правительства Российской Федерации № 307, которым утверждены Правила предоставления коммунальных услуг гражданам. Анализ указанного документа выявил ряд вопросов, однако в письмах-разъяснениях к этому постановлению Министерства регионального развития Российской Федерации от 13 февраля 2007 года № 2478-РМ/07 и от 4 июня 2007 года № 2479-РМ/07, № 10611-ЮТ/07 на большую часть этих вопросов ответов нет.

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

↑ «Имущественные отношения в РФ», № 5 (май) 2008, стр.35-40.

РКЦ как основа единой городской информационной системы

2008-09-19T16:07:55Z

BenderBot: 1 версия

Авторы

Кулапин Алексей Иванович, директор МУП «Единый расчетно-кассовый центр г. Саратова», доктор химических наук, депутат Саратовской городской Думы.
Новожилов Владислав Владимирович, первый заместитель директора МУП «Единый расчетно-кассовый центр г. Саратова».

«РКЦ как основа единой городской информационной системы»^[1]

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

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

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

Система стандартов позволила повлиять на снижение разброса в стоимости отдельных видов услуг коммунального назначения по регионам России с 30-50 раз до 15-30, чему способствовало упорядочение формирования себестоимости и тарифообразования. Однако, нельзя не отметить, что принятие Советом Федерации поправки к Закону РФ о продлении сроков перехода на новую систему оплаты жилья и коммунальных услуг увеличивает пропасть между потребностями отрасли в финансировании и возможностью государства поддерживать эти процессы.

В органах местного самоуправления, понимающих это, как правило, активно работают в двух направлениях:

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

Многие регионы идут по пути увеличения уровеня оплаты населением коммунальных услуг сверх установленных субъектом Федерации значений, понимая, что переход на 100% оплату является единственно выходом в ситуации реального финансирования при рыночных методах хозяйствования.

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

На наш взгляд, востребованы те РКЦ, которые могут корректно вести учет потребляемых жителями услуг, производить начисление, прием и перечисление средств поставщикам услуг. При этом не следует забывать, что в условиях реформирования ЖКХ и прихода в отрасль частного капитала неизбежна конкуренция поставщиков. Опыт Саратова показывает, что в течение времени происходит не только замена одних поставщиков другими, но и острая конкуренция между компаниями, управляющими жилищным фондом.

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

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

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

В качестве преимуществ организации системы управления коммунальными платежами на базе современного РКЦ можно отметить следующие аспекты:

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

Построение системы управления коммунальными платежами на базе городского РКЦ, оперирующего единой городской базой данных, предоставляет органам местного самоуправления эффективный инструмент для управления. Эффективность этого инструмента выражается в:

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

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

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

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

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

Такой подход требует серьезного технического обеспечения. Только за один год работы с новым программно-технологическим комплексом МУП «ЕРКЦ г. Саратова» увеличило собственную базу данных более чем на 90 миллионов финансовых проводок. Не каждое техническое решение способно выдержать такую нагрузку.

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

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

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

Но создание стабильно работающей системы обработки данных — это далеко не исчерпывающая задача РКЦ. Не менее важным следует считать и повышение собираемости платежей, что невозможно без обеспечения удобства жителям муниципалитета при оплате жилищно-коммунальных услуг. Для этого необходимо создавать сеть абонентских и кассовых пунктов. С одной стороны, современные информационные технологии позволяют одному оператору обслуживать до 8-10 тысяч лицевых счетов. С другой — нельзя не принимать во внимание и то, что существуют обособленные районы города, в которых независимо от количества проживающих обязательно должна быть возможность для работы с населением. Оптимизация топологии пунктов по работе с населением требует применения технологий маркетинга и социологии.

МУП «ЕРКЦ г. Саратова» на сегодняшний день обслуживает почти 200 тысяч лицевых счетов жителей города. Для обеспечения удобства жителей, предприятием создана широкая сеть собственных пунктов. Она насчитывает 25 абонентских и 7 отдельных кассовых пунктов. Все они через высокопроизводительные каналы связи работают с единой базой данных. Всего для обработки обращений населения и бесперебойного приема платежей на предприятии функционирует 54 автоматизированных рабочих места операторов абонентских пунктов и 26 рабочих мест операторов кассовых пунктов.

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

На сегодняшний день создана и функционирует разветвленная сеть по сбору платежей по платежному документу МУП «ЕРКЦ г. Саратова». Платежи принимаются всеми отделениями управления федеральной почтовой службы (62 пункта приема), отделениями Сбербанка (40 пунктов), десятью коммерческими банками. Всего на территории города заплатить за жилищно-коммунальные услуги по платежным документам МУП «ЕРКЦ г. Саратова» можно в 179 местах.

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

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

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

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

Актуальность базы данных РКЦ сохраняется в течение времени по определению. Учитывая входящие информационные потоки из различных источников и постоянно находясь под контролем населения, ревностно отслеживающего свои данные, влияющие на начисления за ЖКУ, база данных РКЦ всегда будет актуальнее, чем информация иных служб городского хозяйства. Поэтому логично использовать базу данных РКЦ в качестве основы для создания городской информационной системы.

Уже на первом этапе формирования такой системы пользователями и одновременно поставщиками информации в единую систему должны стать:

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

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

↑ Ежемесячный журнал руководителя и главного бухгалтера «ЖКХ», №9, сентябрь 2004, стр. 36-39.

Задачи информационных расчетных центров в реализации новых положений жилищного законодательства

2008-09-19T16:07:50Z

BenderBot: 1 версия

Автор: Кулапин Алексей Иванович, председатель Ассоциации расчетно-кассовых центров Саратовской области, директор «Единого расчетно-кассового центра г. Саратова, депутат Саратовской городской Думы.

«Задачи информационных расчетных центров в реализации новых положений жилищного законодательства»^[1]

В 2005 г. реформирование ЖКХ России вступило в стадию интенсивного практического воплощения и активного юридического закрепления.

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

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

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

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

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

В рамках своего доклада я остановлюсь лишь на некоторых выявленных проблемных аспектах с целью доказать необходимость проведения совместных согласованных действий по всем направлениям реализации обозначенных законодательных инициатив в сфере ЖКХ.

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

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

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

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

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

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

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

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

Еще один аспект. Для осуществления расчета платы за жилищно-коммунальные услуги (при их непредоставлении или ненадлежащем качестве), а также в случае перерасчета платы за отдельные коммунальные услуги при временном отсутствии граждан по месту жительства очень важен тот факт, что определение порядка и методики расчета платы в этом случае отнесено новым Жилищным кодексом к компетенции Правительства РФ.

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

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

Заложенная в Жилищном кодексе РФ возможность дифференцирования тарифов и введения тарифных планов также должна найти свое реальное воплощение. Право потребителя пользоваться оптимальным для него тарифным планом, гарантирующим установленный объем и степень качества предоставляемых жилищно-коммунальных услуг, в первую очередь, должно обеспечиваться биллинговой составляющей. Корректный учет жилищно-коммунальных услуг — это не только возможность оптимизировать расходы на их потребление или производство, это не только залог удовлетворенности как получателя, так и поставщика данных услуг, но еще и общая адекватность протекающих социальных процессов.

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

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

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

Получается, что перед такими структурами, как органы социальной защиты встает выбор — организации информационного взаимодействия с несколькими десятками управляющих и ресурсоснабжающих организаций; либо работа с одной уполномоченной организацией в рамках единой базы данных и одного программного продукта. Логистические и транзакционные издержки этих вариантов работы несоизмеримы. Это подтверждает то, что должен действовать централизованный и предельно понятный всем участникам процесса интегратор, которым может быть именно информационный расчетный центр, качественно обеспечивающий функции по формированию, координации и актуализации всех информационных и финансовых потоков в сфере ЖКХ.

Эффективный интегратор должен:

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

Значение информации как основы для принятия экономически корректных и своевременных решений очень велико. Опыт реализации реформы социальной поддержки населения в соответствии с Федеральным законом от 22 августа 2004 года № 122-ФЗ показал, что недооценка информационного и соответствующего коммуникационного обеспечения может привести к нарушениям финансовой стабильности системы ЖКХ и, как следствие, ухудшению уровня жизни значительной части населения.

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

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

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

↑ Всероссийская конференция руководителей предприятий ЖКХ, Москва, 10 октября 2005.

Команда ИТ-проекта: как избежать проблем

2008-09-19T16:07:41Z

BenderBot: 1 версия

Алексей Кайдалов, ведущий эксперт ООО «Заказные ИнформСистемы»
«Команда ИТ-проекта: как избежать проблем»^[1]

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

↑ Публикация на сайте Cnews, раздел «Аналитика», 20 июня 2005.

Новый коллективный разум

2008-09-19T16:07:36Z

Пресс-служба:

Алексей Кайдалов, ведущий эксперт ООО «Заказные ИнформСистемы»
«Новый коллективный разум»^[1]

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

↑ "Банки и технологии", № 4-2004, стр.12-17.