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

Облачная инфраструктура ЦОД: готовность оператора и заказчика

2014-09-04T11:06:31Z

AlenaKolyaseva:

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

«Технологии и средства связи»: С какими проблемами сталкивается оператор при предоставлении серверных мощностей облачного ЦОД своим заказчикам?

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

«Технологии и средства связи»: Какие требования предъявляют к оператору облачного ЦОД потенциальные клиенты?

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

«Технологии и средства связи»: Что необходимо заказчику для трансформации своей IT-инфраструктуры для перехода в облако?

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

«Технологии и средства связи»: Что мешает более активному переходу заказчиков к облачным технологиям?

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

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

Репликация: База Знаний «Заказных Информ Систем» → «Облачная инфраструктура ЦОД: готовность оператора и заказчика»

Российский рынок интернет-торговли стал крупнейшим в Восточной Европе

2014-09-04T09:31:03Z

AlexandraVelyaninova:

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

По данным Euromonitor International (EI), российский онлайн-рынок на сегодняшний день является крупнейшим в Восточной Европе. Объем рынка российского интернет-ритейла составляет примерно 10,5 миллиардов долларов.

«Российская газета»: Что, на ваш взгляд, является главными стимулами развития электронной торговли в России?

А. Баранов: Развитие электронной торговли в России связано со следующими факторами:

проникновение Интернета не только в Москве, но и в средних и небольших городах (в настоящий момент 43 % россиян хотя бы раз в сутки выходят в Сеть);

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

рост доверия к электронной торговле: покупки через Интернет становятся все более привычными;

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

«Российская газета»: Что тормозит развитие рынка?

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

Кроме того, эффективная электронная торговля требует полного пересмотра подхода к управлению товарным запасом, который существенно отличается от привычной «офлайновой» схемы. Многим интернет-магазинам (в частности, одежды и обуви) критически важно научиться работать с массовыми отказами от товара после примерки (в среднем от купленной в Интернете одежды отказываются 30–50 % покупателей).

«Российская газета»: Каковы перспективы развития рынка?

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

«Российская газета»: Спасибо за беседу.

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

Отзыв о книге Донеллы Медоуз «Азбука системного мышления»

2014-09-04T08:56:04Z

OlgaChekhunova:

На портале theRunet.com опубликован отзыв Евгении Удаловой, руководителя отдела персонала нашей компании, о книге Донеллы Медоуз «Азбука системного мышления». О том, чем эта книга может быть полезна для HR-специалистов, работающих в сфере IT, — в материале «4 лучших книги для специалиста по работе с персоналом».

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

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

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

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

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

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

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

А сало русское едят (о предпочтениях банков в IT)

2014-09-04T08:48:01Z

AlexandraVelyaninova:

Сергей Тихомиров, первый заместитель генерального директора и руководитель направления «Финансовые институты», рассказал порталу «Bankir.Ru» о перспективах развития рынка банковской автоматизации и о том, насколько конкурентноспособны российские IT-решения в сравнении с западными. Комментарии Сергея опубликованы в материале «А сало русское едят». Мы публикуем полную версию интервью.

Bankir.Ru: Предпочтение банков в IT — «покупай российское» или поддержка импорта? Насколько конкурентоспособны российские вендоры в сравнении с транснациональными корпорациями, если речь не идет об IT-решениях, призванных не только генерировать отчетность в соответствии с требованиями регулятора?

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

Стоит отметить, что в разных областях банковской деятельности применимость западных решений различна. Ключевую роль здесь играют три фактора: необходимость и объемы поддержки российской специфики, потребность в современных технологиях и значимость юзабилити и дизайна интерфейса. Если разложить автоматизацию на стандартные слои front — middle — back — accounting, то достаточно очевидно, что во фронт-офисе соответствие западных решений перечисленным требованиям максимально, а с переходом на каждый следующий слой оно падает.

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

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

Bankir.Ru: По каким причинам банки меняют АБС?

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

Bankir.Ru: Многие банки заявляют о сокращении IT-расходов. Тенденция такова: купить лучшее решение, но подешевле. Какие вендоры выиграют на этом поле — российские или зарубежные?

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

Bankir.Ru: Почему мало успешных внедрений западных АБС? Работают ли, на ваш взгляд, западные вендоры на адаптацию к российским реалиям? Банки при замене АБС отказываются от «монолитных» IT-решений, переходят по возможности к компонентной архитектуре — это реальность сегодняшнего дня. Кто займет больше места и принесет больше «строительных кубиков» — российские или зарубежные вендоры?

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

Bankir.Ru: Вендоры говорят, что сейчас «рынок заказчика». Что просят банки? Смотрят ли они вперед и что там видят? Способны ли вендоры предложить рынку «новый взгляд», новый вектор развития, как это было двадцать лет назад, когда все только начиналось в российской автоматизации или работают исключительно на конъюнктуру?

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

Bankir.Ru: Проблема технической зависимости от вендора — на какие уступки вы способны, чтобы выиграть на конкурентном поле? Не смущает ли вас желание банков создавать свои собственные IT-компании? Как воспринимает технические нововведения персонал банков?

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

Bankir.Ru: Каковы ТОП-5 направлений, по которым в ближайшие годы будут развиваться банковские технологии?

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

1) разработка информационной архитектуры;

2) интеграционные решения;

3) интернет-решения;

4) мобильные решения;

5) учетно-аналитические решения.

Bankir.Ru: Спасибо за беседу.

Репликация: База Знаний «Заказных Информ Систем» → «А сало русское едят (о предпочтениях банков в IT)»

Удаленная работа: за и против

2014-09-03T12:21:58Z

AlenaKolyaseva:

На портале «Планета HR» опубликован комментарий Евгении Удаловой, руководителя отдела персонала нашей компании, о преимуществах и недостатках удаленной работы. Поводом к обсуждению стал полный отказ Yahoo от такой формы организации труда и категорическое требование присутствия сотрудников в офисе по расписанию. Насколько оправданна удаленная работа? Почему в нашей компании это только возможность, но не правило? И что мы понимаем под принципом collaboration? Об этом — в материале «Удаленная работа: за и против».

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

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

Итак,

компания CUSTIS представляет IT-индустрию, так что вопросы, связанные с гибким подходом к организации труда, для нас совсем не новы;

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

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

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

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

Ответ очень простой, давайте еще раз вдумаемся в эти цифры:

объем знаний в области технических наук удваивается каждые 2 года;

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

многие компании уже сейчас пересматривают свои планы раз в 2–3 месяца, что соответствует запросам стремительно меняющейся внешней среды.

Темпы изменений с каждым годом растут, а ведь компании важно не просто сохранить свои позиции на рынке, но и усилить свои конкурентные преимущества.

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

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

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

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

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

Как помочь сотрудникам жить счастливой и здоровой жизнью?

2014-09-03T09:44:14Z

OlgaChekhunova:

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

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

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

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

выбрать оптимальный график работы, определив удобное время прихода и ухода;

произвольно распределить свою загрузку в течение недели: в какой-то день работать больше, в какой-то — меньше;

несколько дней в месяц работать удаленно, например из дома или кафе;

среди недели взять оплачиваемый отгул и выйти на работу в выходной (в нашем офисе комфортные условия работы 24 часа в сутки 7 дней в неделю).

Это позволяет работать в более привычном и удобном режиме: мучительно в 9:00 видеть на работе «сов», которые литрами заливают в себя кофе, а на вечерних совещаниях пытаться обсуждать серьезные вопросы с дремлющими «жаворонками».

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

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

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

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

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

Репликация: База Знаний «Заказных Информ Систем» → «Как помочь сотрудникам жить счастливой и здоровой жизнью?»

Должно ли описание вакансии нести информацию о компании?

2014-09-03T09:30:15Z

AlenaKolyaseva:

На портале «Планета HR» опубликован комментарий Анны Рид, HR-партнера направления «Финансовые институты», о построении текста вакансии. Почему так важна формулировка открытой вакансии? Каковы этапы ее создания? Чем вакансия отличается от позиции, а внутренняя формулировка — от внешней? Об этом — в комментарии к материалу «Должно ли описание вакансии нести информацию о компании?».

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

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

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

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

Путь от появления потребности в новом сотруднике и определения его позиции до формулировки вакансии состоит из нескольких этапов.

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

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

HR-партнер и руководитель должны ответить на следующие вопросы:

Почему выделяется позиция?

Под какой объем деятельности?

Какова предполагаемая структура работ по видам деятельности и как она распределена по временной шкале?

Какой квалификационный уровень требуется, каков уровень сложности деятельности?

Какие базовые и специфические компетенции требуются на этой позиции?

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

В какой срок нужно закрыть позицию?

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

перераспределением загрузки среди имеющихся сотрудников отдела;

перестроением процессов группы для повышения эффективности работы;

ротацией персонала (из смежного отдела или другого направления).

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

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

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

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

На этом этапе мы дополняем описание позиции специфическими для компании и проекта особенностями, такими как:

требуемый опыт (на каких должностях, в каких компаниях);

карта мотивации кандидата;

возможности и перспективы для кандидата;

уровень компенсации;

личностные качества и т. д.

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

Таким образом, комплексный подход к открытию и описанию вакансий помог нам:

создать общее информационное пространство руководителя, HR-партнера, менеджера по подбору и избежать ошибок недопонимания;

сделать описания вакансий более понятными и привлекательными;

повысить вовлеченность менеджера по подбору;

уменьшить риск несовпадения ожиданий компании и нового сотрудника;

повысить эффективность и качество подбора.

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

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

Коммунальный коммунизм (о причинах кризиса в ЖКХ)

2014-09-02T09:43:59Z

AlenaKolyaseva:

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

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

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

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

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

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

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

Репликация: База Знаний «Заказных Информ Систем» → «Коммунальный коммунизм (о причинах кризиса в ЖКХ)»

Сквозное управление ИТ в банке: от бизнеса до «железа»

2014-06-04T12:33:25Z

AlexandraVelyaninova:

В «Национальном банковском журнале» (№5/2014) опубликовано интервью с Сергеем Тихомировым, первым заместителем генерального директора нашей компании, и Александром Габидулиным, заместителем генерального директора по ИТ-инфраструктуре, посвященное сквозному управлению ИТ в банке. Почему происходит рассогласование ИТ- и бизнес-векторов в финансово-кредитных организациях? Что понимается под сквозным управлением ИТ и какие преимущества оно может дать бизнесу? Почему ИТ-инфраструктурное подразделение стоит рассматривать как полноценного бизнес-партнера? Об этом — в интервью «Сквозное управление ИТ в банке: от бизнеса до «железа» на сайте и в бумажной версии журнала.

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

NBJ: Что изменилось за последние годы, что мы говорим о необходимости изменения подхода к управлению ИТ в банках? Почему текущие схемы работы становятся менее эффективными?

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

NBJ: А что мы имеем сейчас?

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

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

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

NBJ: Но может, некоторая обособленность естественна? В конце концов, предметы и объекты деятельности у них действительно разные.

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

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

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

А. Габидулин: Потеря эффективности — это еще полбеды, ведь банк упускает возможности, которые могут дать актуальные тренды в области ИТ-инфраструктуры, а значит, теряет потенциальные конкурентные преимущества.

NBJ: Например?

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

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

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

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

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

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

NBJ: Спасибо за беседу.

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

DDD - модель вместо требований (Максим Цепков на AnalystDays-2014)

2014-05-25T21:26:24Z

MaksTsepkov:

----

Репликация: База Знаний «Заказных Информ Систем» → «DDD - модель вместо требований (Максим Цепков на AnalystDays-2014)»

Этот доклад был рассказан на конференции AnalystDays – 2014. Он сделан на основе одноименного доклада на HappyDev – 2013, при этом дополнительно рассмотрены варианты разделения ответственности между аналитиком и разработчиком в разных проектах и позиционирование проектирования по моделям в этих вариантах, а также тема разделения контекстов в DDD.

Доклад на сайте конференции
Презентация на Slideshare
Видео на vimeo

DDD - модель вместо требований (Максим Цепков на HappyDev-2013)

2014-02-16T15:03:07Z

MaksTsepkov:

----

Репликация: База Знаний «Заказных Информ Систем» → «DDD - модель вместо требований (Максим Цепков на HappyDev-2013)»

Доклад на сайте конференции

Сталкивались с тем, что требования сложно формализовать и поддерживать актуальность?

Есть много подходов - user story, use case и т.д., но все они описывают в основном поведенческие аспекты. А что делать, если мы работаем в сфере, где бизнес-требования достаточно сложны и объекты меняют поведение в зависимости от контекста?

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

Роли в проекте: как поделить поляну ответственности (Максим Цепков на HappyDev-2013)

2014-02-16T15:02:43Z

MaksTsepkov:

----

Репликация: База Знаний «Заказных Информ Систем» → «Роли в проекте: как поделить поляну ответственности (Максим Цепков на HappyDev-2013)»

Доклад на сайте конференции

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

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

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

Миссия как инструмент против трений

2014-01-14T16:48:49Z

AlexandraVelyaninova:

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

Chief Time: Нужно ли руководителю осознавать предназначение своей компании?

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

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

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

CT: Что дает понимание предназначения владельцу компании, что — сотрудникам и что — клиентам?

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

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

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

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

CT: Как сформулировать для себя миссию своего бизнеса?

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

CT: Формулировка миссии для покупателей, для сотрудников и для собственников — должны ли они отличаться друг от друга?

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

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

ИТ-инфраструктура современных компаний: общие тенденции

2013-12-25T13:03:22Z

VladMarkov: переименовал ИТ-инфраструктура современных компаний:общие тенденции в ИТ-инфраструктура современных компаний: общие тенденции: Заг…

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

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

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

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

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

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

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

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

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

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

Эти тенденции делают особенно значимыми следующие требования к ИТ-инфраструктуре (см. рисунок):

бесперебойная работа;

масштабируемость;

безопасность;

скорость изменений;

прозрачность и управляемость;

адекватная стоимость владения.

Требования современных крупных компаний к ИТ

Рассмотрим, как перечисленные требования отражаются в необходимых свойствах ИТ современных крупных компаний.

Управление справочными данными:гибкий подход

2013-12-23T17:14:50Z

KseniyaKirillova:

Михаил Заборов, руководитель стратегических проектов, рассказал журналу Intelligent Enterprise о подходах и практиках управления справочными данными в компаниях, также об ограничениях применения MDM-систем. Почему универсальная MDM-система является всего лишь одним из способов организации работы со справочными данными? Что необходимо для эффективного управления нормативно-справочной информацией организации? Об этом — в статье Управление справочными данными: гибкий подход на сайте и в бумажной версии журнала.

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

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

Корпоративный ЦОД: за и против

2013-12-23T15:50:14Z

AlexandraVelyaninova:

В журнале «Технологии и средства связи» (№4/2013) опубликована статья ведущего системного инженера Дмитрия Морозова, посвященная вопросам эффективной эксплуатации корпоративных ЦОД, плюсам и минусам размещения IT-инфраструктуры в коммерческих и корпоративных ЦОД, а также особенностям управления IT-инфраструктурой в привязке к бизнес-процессам организации. Об этом — в статье «Корпоративный ЦОД: за и против» на сайте и в бумажной версии журнала.

Клиентоориентированность — главное условие успешной работы на ИТ-рынке

2013-12-23T14:10:50Z

OlgaChekhunova:

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

DDD для корпоративных систем - модель вместо требований (Максим Цепков на ЛАФ-2011)

2013-11-19T21:18:24Z

MaksTsepkov:

Доклад на ЛАФ-2011

Видео с конференции http://blogs.uml2.ru/post/Maksim-Cepkov-Domain-Driven-Design-model-vmesto-trebovaniy

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

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

Видео с конференции http://blogs.uml2.ru/post/Maksim-Cepkov-Domain-Driven-Design-model-vmesto-trebovaniy

Презентация

Репликация: База Знаний «Заказных Информ Систем» → «DDD для корпоративных систем - модель вместо требований (Максим Цепков на ЛАФ-2011)»

Highload-2013: Отчёт Виталия Филиппова

2013-11-11T22:04:47Z

VitaliyFilippov: /* Как рассуждать о производительности хранилищ баз данных / Mark Callaghan (Facebook) */

Информация о конференции, организация:

Highload-2013, «Конференция разработчиков высоконагруженных систем». Проходила в очередной раз в конференц-зале гостиницы Radisson на м. Киевская.
Самая первая и самая распиаренная из Бунинских конференция. Билет стоил аж 21000, плюс ещё были отдельные «учебный» и «VIP» дни (на которых я, естественно, не был).
Хайлоад начался с хайлоад-очереди на регистрацию. В разные обработчики она, правда, почему-то была разная (очередь с приоритетами, где каждый оценивает свой приоритет сам?), и встав в другую, ты терял времени на порядок-два меньше.
Вайфай нормально не работал, до отваливания в нём удавалось посидеть минут 5.
С едой всё было более-менее в порядке — кофе-чай всё время, 2 перерыва, каждый из которых для части людей — кофе-брейк с плюшками, а для другой части — обед (балансировали нагрузку талонами). Небольшие трудности с обедом — народу много, места сесть не хватало, часть еды быстро кончалась. Но голодным там всё равно никто не оставался.
Дали большую кучу раздаточных материалов — книжку с частью докладов с прошлой конференции, диск, рекламу, 3 блокнота… Полезный элемент — в этом году вместо ахтунг-стайл красной авоськи дали сумку для ноутбука, в которую и был упакован весь выданный crap.

Общая атмосфера:

Атмосфера в целом какая-то «коммерческая», видно, что компании туда ходят уже по накатанной для регулярного пиара.
Докладчики (компании) — всё одни и те же лица, посетители — наоборот, похоже, исключительно новые. Правильно Стас выразился — это как с борделем, нормальный человек ходит туда 1 раз в жизни; это ты ходишь постоянно, и тебя уже ничем не удивишь.
Девушек на конференции не было почти совсем, «радостную» программистскую тусовку разбавить было некем.
Многие зарубежные «звёзды», как обычно, лили воду, содержательной части в докладах от FB, например, процентов 10.
Было много докладов от одних и тех же компаний — может это и не плохо, но по-моему свидетельствует о неком спаде доступного разнообразия (или слабом подборе). Ну и badoo (которое сайт знакомств и вообще непонятно, почему в 21 веке имеет столько юзеров) уже слушать как-то неинтересно. Примеры повторов:
По 3 доклада от Badoo и 2ГИС; по 2 от Одноклассников, Facebook, Monty Program AB, Qrator/HLL, mail.ru, HashiCorp. К этим в общем-то претензий нет, понятно, что вторых таких же чуваков, как Qrator, найти сложно.

Блог Максима Цепкова - оглавление

2013-11-11T18:50:33Z

MaksTsepkov:

Первоначально я вел блог на uml2.ru и продолжаю постить туда ссылки на новые статьи
Потом больше года публиковался на SoftwarePeople Доступ утрачен с закрытием портала
Потом был здесь, на сайте компании Блог:Максима Цепкова
А с 19.05.2014 переехал на личный сайт http://mtsepkov.org/Blog и туда скопированы посты с данного сайта, восстановлены посты с SoftwarePeople и будут скопированы с uml2.ru

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

Блог:Максима Цепкова

Мои посты на SoftwarePeople (и немного на uml2)

2013-06-11 По следам MS DevCon-2013
2013-05-28 AnalystDays-2013
2013-04-30 SQAdays-13 (весна 2013)
2013-04-15 SoftwarePeople-2013
2013-04-11 Мастер-классы Эдварда Йордана перед SoftwarePeople-2013
2013-03-31 AgileDays 2013 - между скрамом и будущим
2013-03-29 Как появляется PBL - Jeff Patton на AgileDays
2013-03-22 Клуб директоров по разработке встреча 21.03
2013-03-16 Enterprise Developers Conference
2013-03-10 OMG Essence
2013-02-22: MODELSWARD - подвожу итоги
2013-02-20 MODELSWARD - первые впечатления
2012-12-20 Проектирование программ: мастера и самоучки
2012-12-02 SQAdays-12, день второй
2012-12-01 SQAdays-12, день первый
2012-11-29 KM Russia-2012, день второй
2012-11-28 KM Russia-2012, день первый
2012-11-19 SPMconf-2012 Минск - день второй
2012-11-17 SPMconf-2012 в Минске - день первый
2012-11-13 ReqLabs-2012 в Киеве
2012-11-03 SECR-2012, день второй
2012-11-02 SECR-2012 - день первый
2012-10-31 SECR-2012, курс Билла Кертиса
2012-10-25 Гики и Менеджеры
2012-10-25 Пока мы наступаем, Microsoft меняет рельеф местности
2012-08-07 Запад и Япония: два взгляда на бизнес-процессы
2012-05-01 Agile как IT-форма современного менеджмента

Блог на uml2.ru

2012-06-25 ЛАФ-2012
2012-06-11 AgileKitchen 11.06.2012
2012-06-01 Заседание Клуба директоров по разработке об архитектуре
2012-05-28 AnalystDays-1
2012-05-13 ADD-2012 - передний край разработки
2012-04-29 Изменим мир к худшему!
2012-04-29 Три мира программистов
2012-04-24 SQAdays весна 2012 - день второй
2012-04-22 SQAdays весна 2012 - первый день превзошел ожидания
2012-04-18 Желание и Возможность формулируются на разных языках
2012-04-13 SoftwarePeople 2012 - продолжение
2012-04-10 SoftwarePeople 2012 день первый
2012-04-01 Впечатления Atlantic Systems Guild
2012-03-28 Agile как IT-форма современного менеджмента
2012-03-25 Agile Days-2012, день второй
2012-03-24 Agile Days-2012, день первый
2012-01-18 Отчет Управление знаниями - KM Russia 2011
2011-12-25 Культуры IT-компаний
2011-12-12 KMrussia - объясняшки
2011-12-03 10-я конференция SQA Days - день второй
2011-12-02 10-я конференция SQA Days - день первый
2011-11-28 Конференция SPM Conf 2011
2011-11-24 Бизнес-форум управления знаниями - день второй
2011-11-23 Бизнес-форум управления знаниями KMRussia-2011
2011-11-20 Agile и CMMI
2011-11-06 Карта компетенций SFIA
2011-11-03 SECR-2011 завершился
2011-11-03 SECR-2011. Промежуточные итоги
2011-10-31 SECR-2011 день первый - банки
2011-10-26 Снова об Archimate
2011-10-15 Осень - время конференций
2011-06-28 Послесловие к ЛАФ-2011
2011-06-11 Роль аналитика в разработке
2011-05-22 Черный лебедь Талеба
2011-05-13 О разработки фреймворков...
2011-05-06 ADD-2011 - Макс Цепков
2011-05-03 Конференция ADD-2011
2011-04-09 Тренинг Нила Мейдена на SoftwarePeople 2011
2011-04-08 Возвращаясь к REQ-labs
2011-04-08 SoftwarePeople 2011 - день второй
2011-04-07 SoftwarePeople 2011 - день первый
2011-04-04 Впечатления о REQ-Labs 2011 - Макс Цепков
2011-03-13 Тренинг Книберга по Agile - Макс Цепков
2011-03-13 AgileDays-2011 - Макс Цепков
2011-02-23 Getting Things Done
2011-01-27 Конференция и ее результаты
2011-01-21 Требования и стандарты на них
2011-01-13 Стандарты представления знаний
2011-01-07 О стандартах архитектуры
2011-01-05 ArchiMate
2011-01-02 Архитектурные метафоры строительства в IT
2010-12-21 Макс Цепков - отчет о SECR-2010
2010-12-14 О дорогой автоматизации
2010-12-09 Как бороться Аналитику с рутиной
2010-11-29 Мысли - имеют продолжение
2010-11-12 Конференция Управление знаниями - 10.2010
2010-11-01 Рейнвотер. Как пасти котов
2010-10-26 Конференция Управление знаниями
2010-10-25 Осень - время конференций. Управление знаниями.
2010-10-15 SECR-2010 закончился
2010-10-14 SECR-2010 первые впечатления

На этом мой внешний блог заканчивается.

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

SECR-2013: Отчёт Виталия Филиппова

2013-11-01T13:19:13Z

VitaliyFilippov: /* Осторожно: патентные тролли! Теория, практика и актуальные примеры — Юрий Бардмессер, Bardmesser Law Group */

Конференция «Software Engineering Conference Russia — 2013». Даты проведения — 24-25 октября 2013.
От нас ходило 8 человек, но я, по-моему, так выбирал доклады, что с другими пересекался мало. Хорошо — значит, отчёт будет полезнее :)
Темы — разные, качество докладов — среднее, были интересные, но много и всякой фигни, в том числе долгих «круглых столов».
Докладов много, 4 параллельных сессии в первый день, 5 параллельных сессий во второй.
Место проведения: Digital October. Типичная для него проблема — всё время в проходах ставят мелкие столики, вокруг них толпится народ, и в итоге фиг пройдёшь, всё время расталкивать кого-то приходится.
Торможений в организации не наблюдалось.
Презентации уже есть на сайте — http://2013.secr.ru/, и это тоже хорошо.
Еда: Кофечай был всё время, это хорошо. В перерывах давали довольно гнусные бутерброды, претендующие на вид «мини-бургеров», и печеньки, которые мгновенно сжирались. Обед нормальный, люди как всегда выстраивались в длиннющие очереди, а я применял хак.
Ну какой нафиг software engineering может быть в 9:00? Хоть бы в 10, что ли… :)

DDD: проблемы и решения в отражении модели предметной области в код (Максим Цепков на Software People 2013)

2013-10-21T21:38:19Z

MaksTsepkov: /* Краткое содержание доклада */

Доклад был сделан на конференции SoftwarePeople-2013.

Современные технологии обслуживания клиентов в банках

2013-09-06T13:45:22Z

KatyaNikolaeva:

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

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

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

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

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

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

Горячая замена

2013-07-24T16:33:25Z

AlexandraVelyaninova:

Михаил Заборов, наш заместитель генерального директора по стратегическим проектам, рассказал журналу IT Manager о смене управленческого ПО в компании. Почему компании решаются на замену ключевой ИТ-системы? Что лучше — дать ей «долго умирать» или сменить «резким движением»? Как выбрать новую систему и не повторить ошибки прошлого? Об этом — в статье «Горячая замена» на сайте и в бумажной версии журнала. Мы публикуем полный текст беседы с Михаилом.

IT Manager: В каких случаях и по каким причинам, исходя из вашего опыта, компании обычно принимают решение о смене ключевой информационной системы, например, ERP?

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

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

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

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

Когда смена системы действительно неизбежна?

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

По каким критериям вы рекомендуете выбирать новую систему?

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

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

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

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

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

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

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

Какие трудности характерны для ИТ-проектов, связанных с заменой одной информационной системы на другую?

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

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

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

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

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

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

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

Управление фирмой, оказывающей профессиональные услуги

2013-07-24T09:27:30Z

AlexandraVelyaninova:

Максим Михалев, наш директор по развитию бизнеса, рассказал порталу Bankir.Ru об одной из наших любимых книг Дэвида Майстера — «Управление фирмой, оказывающей профессиональные услуги». Отзыв Максима опубликован на сайте в рубрике «Люди о книгах».

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

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

Майстер определяет и описывает две основные особенности (они же — потенциальные проблемы) консалтингового бизнеса.

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

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

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

Репликация: База Знаний «Заказных Информ Систем» → «Управление фирмой, оказывающей профессиональные услуги»

Эффект модерации (Алишер Якупов, WUD-2011)

2013-07-23T12:19:11Z

VitaliyFilippov:

ADD-3: Отчет Моисеева Андрея

2013-07-23T11:57:29Z

VitaliyFilippov:

Был на конференции ADD-3. Очень понравилась организация конференции - как-то очень уютно и по домашнему всё было. Гораздо лучше, чем на SoftwarePeople-2012. А вот качество докладов в среднем было на мой взгляд хуже. Возможно это частично компенсировалось возможностью комфортного общения с авторами заинтересовавших докладов в кулуарах. Далее подробнее о тех докладах, которые я посетил.

ADD 2010: Отчет Мальцевой Екатерины

2013-07-23T11:56:38Z

VitaliyFilippov:

Highload 2009: Отчёт Виталия Филиппова

2013-07-23T11:54:14Z

VitaliyFilippov:

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

McHost пиарился, привёз голых девок. Ещё только сейчас понял, что большинство презентаций были какие-то уж больно фиговые. 5-6 слайдов на полчаса времени?…

Я рассказывал блиц-доклад PHP-разгон: серебряная пуля из автомата Комменца-Вальтера» (Commentz-Walter). Есть корпоративный отчётик с презентацией и видео.

ЛАФ-2013: Отчет Григораш Н. Ю.

2013-07-16T10:45:41Z

VladMarkov:

Кэширование в веб-приложениях - что, где, когда

2013-05-16T14:06:42Z

VitaliyFilippov: /* Замечания */

Slide Show

Автор: Виталий Филиппов
Нижний колонтитул: Кэширование в веб-приложениях - что, где, когда
Дополнительный нижний колонтитул: Виталий Филиппов, 14:42, 21 июня 2013

Тема: Кэширование в веб-приложениях — «что, где, когда»
Формат: лекция
Лектор: Виталий Филиппов
Дата: 16 мая 2013
Время: 1.5-2 часа
Требования к аудитории: Представление о разработке в целом и интерес к веб-разработке в частности :)
Для просмотра презентации в браузере нажмите на картинку справа.
Для просмотра на мобильных и прочих устройствах — PDF-версия: Media:WebAppCache.pdf

Oracle Day 2012:Отчет Белобородова Дмитрия

2013-05-07T07:07:33Z

DmitryBeloborodov:

Оказание юридической помощи в компании

2013-03-19T18:02:37Z

AlexandraVelyaninova:

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

«БОСС»: Как организовано оказание юридической помощи в Вашей компании? Какова модель юридического направления — собственное подразделение, аутсорсинговая структура или и то, и другое?

Екатерина Родыч: С 2007 года наша компания располагает собственной юридической службой, состоящей из двух человек. Ранее (более пяти лет) компания обходилась без профессионального юридического отдела. В настоящее время до 90% юридических задач решается в нашей компании собственными силами. Конечно, некоторые задачи мы отдаем на подряд, если очевидно, что аутсорсеры справятся с ними быстрее и эффективнее. Это, например, вопросы взаимоотношений с государственными органами.

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

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

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

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

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

«БОСС»: Если есть внутренние юристы, каковы их задачи?

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

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

«БОСС»: Как наиболее целесообразно, с Вашей точки зрения, делить работу между внутренними и внешними юристами?

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

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

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

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

«БОСС»: Каковы требования для подбора юристов? Какова должна быть их степень глубины погружения в специфику компании, с одной стороны, и в те или иные направления юридической помощи, с другой?

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

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

«БОСС»: Где и как Вы находите юристов?

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

«БОСС»: Какие типичные ошибки совершают компании при организации юридической помощи?

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

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

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

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

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

WikiHelp:Расширенная разметка

2013-01-31T10:56:45Z

AndreyMoiseev:

{{#set: |HelpId=AdvancedMarkup |HelpOrder=1100 |ParentMenuId=Markup |HelpContent=WikiHelpContent:Расширенная разметка |HelpDisplay=Расширенная разметка }}

[Исходная статья]

См. подразделы. {{#ask: ParentMenuId::AdvancedMarkup

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/Aggregate/1

}}

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Загрузка произвольных файлов

2013-01-30T10:21:26Z

AndreyMoiseev:

{{#set: |HelpId=AnyData |HelpOrder=400 |ParentMenuId=Media |HelpContent=Справка:Изображения#Загрузка произвольных файлов |HelpDisplay=Произвольные файлы }}

[Исходная статья]

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

Scrum-checklist

2013-01-25T14:42:00Z

VitaliyFilippov:

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

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

Это вольный перевод на русский язык Scrum checklist, составленного Генрихом Книбергом (автор книги «Scrum and XP from the Trenches»)

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

WikiHelp:Возврат к ранней версии

2013-01-24T12:16:36Z

AndreyMoiseev:

{{#set: |HelpId=Undo |HelpOrder=300 |ParentMenuId=CreateArticles |HelpContent=Справка:Возврат к ранней версии |HelpDisplay=Возврат к ранней версии }}

[Исходная статья]

«Возврат к ранней версии» сделать просто.

Последовательность действий:

Откройте статью
Нажмите вкладку «История»
Щёлкните по той ссылке, где указана дата и время нужной версии
Откроется выбранная версия
Нажмите вкладку «Править»
Не внося никаких изменений нажмите кнопку «Записать страницу»

Теперь именно эта версия становится текущей.

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

Внимание! Данная статья выбрана для репликации в SMWiki.

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

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Перенаправление

2013-01-24T12:07:07Z

AndreyMoiseev:

{{#set: |HelpId=Redirect |HelpOrder=200 |ParentMenuId=CreateArticles |HelpContent=Справка:Перенаправления |HelpDisplay=Перенаправление }}

[Исходная статья]

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

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

Для создания на странице перенаправления, напишите в её тексте одну строку:

#REDIRECT [[Название статьи, куда будет перенаправлено]]

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

Внимание! Данная статья выбрана для репликации в SMWiki.

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

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Wiki - что,как и почему?

2013-01-24T11:43:39Z

AndreyMoiseev:

{{#set: |HelpId=AboutWiki |HelpOrder=250 |ParentMenuId=StartWith |HelpContent=WikiWiki |HelpDisplay=Wiki - что, как и почему? }}

[Исходная статья]

WikiWiki (Вики) — гипертекстовая интернет-среда, предназначенная для коллективного редактирования, накопления и структуризации текстовой информации.

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

Термин

Название произошло от гавайского слова «wikiwiki» — «как можно быстрее». Концепция Вики отвечает тому, что первоначально задумывал Тим Бернерс-Ли (Tim Berners-Lee), изобретатель Всемирной Сети: доступность информации онлайн и возможность её быстрого изменения. По крайней мере, так он писал в своей книге «Weaving the Web».

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

Wiki (также WikiWiki, WikiWikiWeb или WikiWeb), — это собрание интернет-страниц, которые можно не только читать, но и изменять онлайн. Как и в WWW, отдельные страницы и статьи соединены между собой ссылками. Для реализации вики-среды создаётся (или добывается уже существующее) подходящее для данных целей ПО — движок вики-сети (вики-движок).

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

Таким образом, «Вики» («ВикиВики») это:

Выражение, означающее «быстро»/ «ненапряжно» на Гавайском.
Принципы ведения вебконтента:
- Простой язык разметки;
- Совместное редактирование множеством пользователей.
- Мгновенная публикация изменений;
- Версионность.
Софт, используемый для этого.
Вебсистема, на базе такого софта.

История

Оригинальная система Wiki была изобретена Вардом Каннингемом. Она была создана для web-узла Pattern Languages Community с целью упростить совместное создание и документирование программных образцов.

Преимущества

Статьи/документы — это плоский текст

Преимущества «плоского» текста (текста, разбитого на строки):

Редактируется в любом текстовом редакторе.
Минимальный «вес» при хранении и пересылке по сети.
Возможно автоматически определять изменения, что дает:
- Параллельное (совместное редактирование);
- Определение авторства каждой строчки;
- Автоматическое разрешение конфликтов;
- Экономная система контроля версий.
- Удобен для автоматической обработки.

Простой язык разметки

Стандартные языки разметки (SGML, HTML, LaTeX):

Сложные для изучения (много элементов, нетривиальный синтаксис);
Возможны трудноуловимые ошибки;
Элементы разметки занимают существенный объем текста (высок «overhead»):
- Долго и трудно набивать текст;
- Текст плохо читаем с экрана.

Плоский текст c простой разметкой:

Быстро пишется;
Легко читается с экрана.

Правка и публикация по месту

Мгновенная публикация:

Для практически всех языков разметки, кроме HTML, нет WYSIWYG-программ просмотра — необходима конвертация в DVI, PostScript, PDF, RTF или тот же HTML, что происходит небыстро.
Публикация по месту позволяет вносить правки в процессе чтения материала (не нужно искать исходные тексты)
Немедленная публикация позволяет сразу же проверить внесенные правки.

Автоматическое построение ссылок

Автоматическая линковка:

Стандартные языки разметки (TeX, LaTeX, SGML) разделяют идентификаторы и названия структурных блоков (секций, глав, разделов), что:
способствует строгой целостности;
Вносит большую «нагрузку» на внесение ссылки
Идентификаторы=Названия=Заголовки
Адаптивная линковка:
- «Опережающие» ссылки на несуществующие статьи;
- Перенаправления ссылок.

Централизованное хранение

При локальной обработке размеченной (HTML, XML, LaTeX, SGML) документации необходимо одновременно знать

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

ВикиВики система сама обеспечивает

централизованное хранение всех блоков текста («статей»)
идентификатор хранения=идентификатор ссылки=названию статьи.

Редактировать может каждый

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

Недостатки

Редактировать может каждый

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

Нет стандартной вики-разметки

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

Разметка не «адаптирована к компьютеру»: Мало программных библиотек стандартного разбора (parsing) документов (в отличие от XML/SGML/HTML).

Ограниченное использование возможностей верстки и полиграфии

Шрифты;
Сложные страницы с полями;
Плавающие объекты и т. п.
Оптимальный кернинг и выравнивание пустых пространств.

Размыта ответственность за содержимое;
Допустима ссылочная нецелостность.

Почему это работает?

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

Когда это не работает?

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

Репликация: База Знаний «Заказных Информ Систем» → «WikiHelp:Wiki - что,как и почему?»

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelpContent:Расширенная разметка

2013-01-23T11:51:45Z

AndreyMoiseev: Новая страница: «См. подразделы.»

См. подразделы.

WikiHelp:Багзилла

2013-01-18T14:57:24Z

AndreyMoiseev:

{{#set: |HelpId=Bugzilla |HelpOrder=200 |ParentMenuId=Integration |HelpContent=Bugzilla |HelpDisplay=Багзилла }}

[Исходная статья]

Логотип Bugzilla

Bugzilla — система отслеживания ошибок, разрабатываемая Mozilla Foundation.

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

Система учета заданий
Система ведения дел
Система регистрации инцидентов
Система управления требованиями, идеями, предложениями, заявками и т.п.
Сайт: http://www.bugzilla.org
Распространение: freeware, open source

Введение

Ключевым понятием системы является Bug (баг) — некоторое задание, запрос, рекламация по поводу ошибки в системе или просто сообщение, требующее обратной связи. Баги регистрируют и предоставляют заинтересованным лицам целостную информации о состоянии этого issue, включая интерфейсы редактирования, запроса и поиска, механизмы почтового и RSS-оповещений.

Bugzilla используют многие компании и организации по всему миру. Из наиболее известных: NASA, IBM, Mozilla, Linux Kernel, Gnome, KDE, Apache Project, Open Office.

Анатомия бага

Сущность Bug имеет набор атрибутов, работа с которыми — редактирование и запросы — является основными сценариями использования Bugzilla. Рассмотрим эти атрибуты.

Структурные атрибуты

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

2. Component (Компонент) - дополнительная структурная классификация. В зависимости от выбранного компонента баг может иметь разный набор компонентов.

Атрибуты жизненного цикла

1. Status (Статус) - основной атрибут, определяющий текущее состояние бага. Отражает меру активности бага от начального состояния, когда он еще не подтвержден как баг, до завершения, когда баг исправлен/решен, что подтверждено Службой Качества. Набор состояний зависит от конкретной инсталляции и настроек Bugzilla. Стандартный набор:

UNCONFIRMED (Не подтвержден)

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

NEW (Новый)

Баг только что зарегистрирован или проверен (если был зарегистрирован в состоянии UNCONFIRMED);

ASSIGNED (Назначен)

Пользователь в поле Assigned To назначен ответственным за этот баг. Баг может быть назначен на другого сотрудника или переведен в состояние NEW;

REOPENED (Открыт заново)

Баг был решен ранее, однако возникла необходимость вернуться к нему (решение было неверным либо неокончательным).

2. Resolution (Резолюция, Решение) - атрибут имеет смысл только для багов в состояниях RESOLVED, VERIFIED, CLOSED. Набор значений атрибута настраиваемый, стандартный набор:

FIXED (Решено) — стандартная резолюция, означающая, что задание выполнено или баг исправлен;
INVALID (Некорректно) — неправильная или некорректная постановка задачи;
WONTFIX (Проблема есть, но решаться не будет) - такая резолюция может быть в отношении request for enhancement, которые хоть и имеют смысл, являются слишком трудновыполнимыми и не являются обязательными;
DUPLICATE (Дублирует) — описанная проблема уже зарегистрирована в другом баге;
WORKSFORME (А у меня работает…) — не удалось воспроизвести описанную проблему ни эмуляцией сценария, ни анализом кода;
MOVED (Перенесено) - проблема перенесена в иную систему-tracker.

Также можно использовать:

LATER (Позже) - задача зафиксирована, но ее решение откладывается на неопределенный срок. Возможно, для ее решение необходимо некоторое внешнее событие или решение других задач. Если в продукте есть веха «неопределенное будущее», разумно также установить target milestone на эту веху.

3. Диаграмма

Жизненный цикл бага (он же граф переходов состояний, workflow) жестко задан в коде и представлен ниже, на графе.

[svg]

Связанные пользователи

Assigned To (ответственный) - пользователь, ответственный за решение (исправление) бага. Подтверждение ответственности происходит при переводе бага из состояний NEW и REOPENED в ASSIGNED.

Reporter (автор) - пользователь, создавший баг.

QA Contact (проверяющий, тестировщик) - пользователь, ответственный за проверку решения бага.

CC List (список наблюдателей) - список заинтересованных в баге пользователей, оповещаемых об изменениях бага.

Описание бага

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

2. Version - номер версии продукта (компонента продукта), в которых наблюдается описанная проблема.

3. Priority - приоритет бага, указывается Assigned To пользователем на основе собственной оценки. Менять приоритет у чужих багов неправильно. Стандартный набор значений — от P1 (наивысший приоритет) до P5 (наименьший).

4. Severity - критичность возникшей проблемы. Список допустимых значений настраивается, стандартный набор:

Blocker - разработка или использования продукта невозможна. Требуется немедленное решение проблемы;
Critical - серьезные проблемы — не работает критичный для использования функционал, наблюдаются серьезные ошибки, связанные с потерей данных и т. п;
Major - проблема связана с важным функционалом продукта;
Minor - проблема связана со второстепенным функционалом продукта или есть легкий обходной путь для решения проблемы;
Trivial - проблема косметического уровня. Например, недоработанный интерфейс - опечатки, не выровненные поля, разнобой цветов и пр.;
Enhancement: Request for enhancement - запрос на усовершенствование.

5. Target (Target Milestone, Веха) - здесь указывается веха (версия, стадия) проекта, к которой баг должен быть решен. Не путать с Version. Например, баг может описывать ошибку, возникшую в версии 1.17, которую было решено исправить к версии 1_21. Веха не обязательно привязана к версии продукта, она может быть привязана к определенному времени. Набор вех — набор единых для каждого продукта событий, которые должны синхронизировать процессы исправления, тестирования и пронесения изменений. Каждый продукт имеет атрибут Milestone URL, содержащий ссылку на документ с именованными и описанными вехами, то есть где будет приведен некоторый Roadmap проекта.

6. Comments - комментарии к багу. Первый — это Description, остальные в форме редактирования бага именуются Additional Comments. Bugzilla рассылает всем связанным с багом пользователям комментарии по почте. В нашей инсталляции Bugzilla есть возможность «Silent» комментариев (checkbox Silent), уведомления о которых не рассылаются по почте. Использовать Silent следует только в том случае, когда информация в комментарии действительно мало интересна — например, worklog-запись о выполненной промежуточной (не решающей баг) работе, или если основная ценность записи - регистрация личных трудозатрат (см. Учет времени (Time tracking)).

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

Зависимости между багами

В Bugzilla регистрируется только один единственный вид зависимостей: «баг X зависит от решения бага Y». Нет разделения структурных зависимостей вида «проблема X подразделяется на проблемы X₁,X₂,X₃» и сетевых зависимостей общего вида, но в целом ничто не мешает представлять структурные зависимости в общем виде («баг X зависит от решения багов X₁,X₂,X₃»).

Зарегистрированные зависимости видны и при просмотре атрибутов отдельно выбранных багов, и могут быть просмотрены в виде ориентированного графа вида:

[svg]

В нашей инсталляции Bugzilla 3 графы зависимостей имеют две дополнительные особенности:

«Важные» баги отображаются более крупными, и их заголовки отображаются прямо на графе. Важными считаются баги, имеющие в трудозатратах или их оценке более 40 часов, либо блокирующие более 4-х багов.
Можно выбрать альтернативный алгоритм построения графов, располагающий баги на поверхности более плотно — twopi - Баг 11407 зависит от решенного 11406 и нерешенного 11405.

Depends on указывает, от решения каких багов зависит данный баг.

В нашей инсталляции Bugzilla показывается также активность по блокирующим багам, а именно:

Процент выполненности блокирующих

Blockers completed ~16%,

Дата последнего изменения блокирующих багов

last changed 2009-02-12 12:57:45

Blocks указывает, решение каких багов зависит от данного бага.

Прочее

URL - ассоциированный с багом URL, указывающий на документ с описанием/постановкой проблемы, если таковой имеется.

В нашей инсталляции Bugzilla можно пользоваться автоматической связью между багом и ассоциированной с каждым Component'ом Wiki-системой, в которой можно делать пристойно отформатированную постановку задачи и даже вести ее обсуждение (См. Интеграция с Wiki).

Whiteboard - текстовая зона свободной формы для задания кратких заметок или тегов к багу.

Keywords - ключевые слова, используемые для пометки и даже для классификации багов.

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

Attachments - прикрепленные к багам файлы (сценарии тестирования, патчи и пр.).

Атрибуты, не используемые в нашей инсталляции Bugzilla:

Platform - вычислительная платформа (железо), на которой наблюдается проблема;

OS - операционная система, на которой наблюдается проблема;

Votes - голоса за баг. Используется в основном для автоматического перевода бага из UNCONFIRMED в NEW.

Поиск багов

Основные атрибуты

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

Хранение запросов

Любой выполненный запрос можно сохранить под выбранным именем (Remember Search As). Ссылка на сохраненный поиск отобразится в линейке Saved Searches, результат запроса можно будет получить за один клик, перейдя по ссылке.

Временные условия

Можно накладывать временные условия на изменение бага, запрашивая только баги, по которым было какое-либо движение (изменение атрибутов, комментарии) в определенном интервале времени — см. группу полей Bug Changes. Интервал времени можно задавать как в абсолютной форме (дата в формате YYYY-MM-DD), так и в форме, относительной текущей дате. Можно сделать хранимый запрос, показывающий только баги, измененные в течение предшествующих 24 часов (или недели, месяца).

Можно использовать слова:

Now — сейчас, разумно использовать для задания верхней границы интервала.
1d — день назад. 2d — два дня назад, 0d — последняя полночь до текущего момента.
1w — то же самое в неделях. 0w — начало недели.
1m — то же в месяцах. 0m — начало месяца.
1y — то же в годах. 0y — начало года.

Можно добавить перед относительными датами знак +, это будет означать, что относительная дата не вычитается из Now, а прибавляется (в будущее).

Полнотекстовый поиск

Начиная с версии 3.0 Bugzilla поддерживает честный полнотекстовый поиск по MySQL FULLTEXT-индексам, а с нашими доработками — и русскоязычную морфологию через стеммер Портера Lingua::Stem::Ru (порт из snowball).

То есть по слову «завтрака» ищется и «завтрак», и «завтраков» и пр.

Искать по словам можно из двух мест: со страницы поиска и из поля Quicksearch в шапке и подвале страниц Bugzilla.

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

Описание синтаксиса:

слово - слово не обязательно должно присутствовать в тексте бага, однако тексты, содержащие данное слово, ранжируются выше других;
+слово - слово обязательно должно присутствовать в тексте бага;
-слово - слово не должно присутствовать в тексте бага. Работает только в сочетании с заданными «положительными» словами — запрос, состоящий из просто «-слова», не вернёт ни один баг;
>слово - повышенная важность слова — больше вклад в ранжирование;
<слово - пониженная важность слова;
+(слово1 слово2) слово3 - группировка выражений скобками. Может быть вложенной;
~слово - ранжировать тексты, содержащие слово ниже других, но не исключать окончательно;
сло* - знак шаблона (wildcard). Такой запрос найдёт и «слона», и «слово»;
"слово, или фраза" - поиск словосочетаний, а не слов. Знаки препинания между словами не учитываются, морфология учитывается.

Слова короче 3 символов в поиске не учитываются.

Boolean Charts

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

[ NOT ]
 ( (Атрибут₁₁ Операция₁₁ Значение₁₁) OR
   (Атрибут₁₂ Операция₁₂ Значение₁₂) OR
   ....)
 [ AND
   (Атрибут₂₁ Операция₂₁ Значение₂₁) OR
   (Атрибут₂₂ Операция₂₂ Значение₂₂) OR
   ....) ]
 [ AND ... ]
 )

Можно накладывать условия по флагам, например: Только баги, содержащие флаги, установленные пользователем user@company.com - «Flag Setter» «is equal to» «user@company.com» Только баги, в которых флаг флаг_утвердить установлен в + - «Flag» «is equal to» «флаг_утвердить+» (аналогично с ?,-)

В Bugzilla 3.0 появилась возможность, ранее имевшаяся только в нашей версии — подзапросы по сохранённым запросам поиска в лице операций matched by saved search (присутствует в списке, возвращаемом запросом таким-то), и not matched by saved search (отсутствует в списке, возвращаемом запросом таким-то).

Например, вы можете сформулировать условие «Блокируется багом из списка, возвращаемого сохранённым запросом поиска My Bugs» — для этого нужно выбрать поле Depends On, операцию matched by saved search и значение My Bugs.

Чуть менее тривиально: можно задавать и запросы вида «найти все мои баги в открытом состоянии, для которых все блокирующие выполнены». Для этого просто нужно создать сохранённый запрос, находящий все выполненные баги, и подменить в запросе из предыдущего абзаца My Bugs этим запросом.

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

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

NOT(Depends On "contains regexp" "[0-9]+" )
NOT(Blocks     "contains regexp" "[0-9]+" )

Списки багов

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

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

Другие полезные возможности вызываются ссылками, расположенными внизу списка:

CSV - выдает список в CSV формате (разделенным запятыми) например, для импорта в программу электронных таблиц;
Buglist feed - выдает список в RSS формате, для чтения через RSS-агрегатор. Список отсортирован по убыванию времени открытия бага, набор полей задан жестко. Может быть полезным для отслеживания поступления новых багов. Для пользователей Mozilla Firefox рекомендуется установить Sage, чтобы использовать Bugzilla-авторизацию, полученную браузером после логина.
Activity feed - показывает RSS-ленту последних комментариев и активности по выбранным в списке багам;
Change Columns - изменение списка атрибутов, показываемых в списке;
Change several bugs at once - если у вас достаточно привилегий, вы можете делать некоторые изменения одновременно над всеми багами в списке — например, сменить ответственного, закрыть группу багов, перенести их в другой Product или Component.
Send Mail to Bug Assignees - отправить письмо всем ответственным по всем багам в списке;
Edit Search - вернуться на страницу запроса для его уточнения;
Remember Search As - присвоить этому запросу имя и сохранить, ссылка на сохраненный запрос отобразится в Saved Searches внизу страницы.

Также есть 3 кнопки:

Long format - показывает несколько багов на одной странице в подробном формате со всеми атрибутами и полными обсуждениями;
XML - даёт возможность выгрузить баги в XML-файл для специальной обработки или импорта в другую Bugzilla;
Time Summary - перенаправляет на страницу просмотра отчётов по трудозатратам по выбранным багам (см. Time Summary).

В нашей инсталляции Bugzilla также есть пункты:

Graph - просмотр выбранного списка багов в виде ориентированного графа;
Summary Report - просмотр табличной агрегации (cм. Отчеты) выбранного списка багов по выбранному срезу (набору атрибутов). Каждая ячейка табличного отчета будет содержать число багов, обладающих соответствующими атрибутами и ссылка на список этих багов. Таким образом, можно легко делать настоящий OLAP drill-down, то есть формулировать "широкий" запрос, переходя от списка к табличному отчету, раскладывать по выбранным измерениям (от одного до трех), и далее получать списки багов по отдельным ячейкам среза, возможно повторяя процедуру раскладки по другим измерениям.

Создание багов

Создание багов вручную

Процедура следующая:

Кликните на ссылке New в нижней или верхней линейке Actions;
Выберите классификацию и продукт;
Заполните поля. Уделите особое внимание атрибутам, идентифицирующим проблему или задание (что, где, насколько срочно) — Component, Version, Severity. Старайтесь дублировать (не обязательно дословно) содержимое Summary в первом комментарии (поле Comments). Атрибут Summary может быть несколько раз отредактирован, что приведет к утере первоначального смысла бага;
Нажмите Commit — это зафиксирует и отправит ваш bug report.

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

Создание бага клонированием другого бага

См. ниже

Импорт из Excel-файла

Bugzilla 3.0 поддерживает массовый импорт багов из Excel-файлов — как бинарных *.xls, так и OOXML *.xlsx.

Система подразумевает, что первая строка Excel-файла содержит заголовки колонок, а последующие — описания багов. Обязательными полями бага являются Product, Component и Summary.

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

После проверки и нажатия Import selected bugs отображается страница с результатами импорта:

с ошибкой, в этом случае ни один из выбранных багов не импортируется;
с успехом, в этом случае будет присутствовать текст Successfully imported X bugs и список ID созданных багов.

Для запуска Excel-импорта:

Кликните на ссылке New в нижней или верхней линейке Actions;
Внизу страницы, под списком классификаций или продуктов, перейдите по ссылке See also: Mass bug import from Excel file;
Выберите Excel-файл кликом по кнопке Обзор…;
Если ваш Excel-файл содержит несколько листов, а вы хотите импортировать только один из них, введите его название в поле Enter sheet name to process. Если вы хотите импортировать все листы, очистите это поле;
После загрузки файла система автоматически проверяет список на наличие уже импортированных ранее багов по точному совпадению названия и максимальному возрасту бага, указываемому в днях в Maximum bug duplicate age. Поэтому, если вы производите повторный импорт файла (модифицированного), укажите такой максимальный возраст, чтобы баги, импортированные ранее из того же файла, попали в этот возраст;
Если вы хотите установить значение определённых полей по умолчанию для всех импортируемых багов, можно выбрать поле, нажать Add field value for all bugs и заполнить выбранное поле;
Нажмите кнопку Parse File.

После нажатия кнопки Parse File будет показана страница с таблицей так, как её видит система. Если колонки в Excel-файле имели названия, совпадающие с названиями полей в Bugzilla, они автоматически сопоставятся нужным полям бага. Если автоматического сопоставления не произошло, кликом на название колонки можно выбрать нужное поле из выпадающего списка.

Значения полей (то есть значения ячеек) должны соответствовать значениям полей в Bugzilla. Все поля отображаются редактируемыми, вы можете исправить любые значения, если увидите несоответствия.

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

После успешно выполненного импорта вы увидите ссылку Import another Excel file — you can bookmark this link as a template. В этой ссылке сохранена информация о сопоставлении полей и значениях полей для всех багов по умолчанию. Поэтому, переходя по ней, вы сможете импортировать другой файл того же формата без лишних усилий. Также вы можете сохранить ссылку в закладки браузера для использования в будущем.

Редактирование багов

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

В основном редактированием основных атрибутов бага занимаются связанные с багом пользователи, указанные в атрибутах Reporter, Assigned To и QA Contact. Регламент работы с багом жестко не определен, любой пользователь, обладающий соответствующими правами, может изменять состояние и атрибуты бага.

Впрочем, обычно:

Reporter ответственен за указание атрибутов, идентифицирующих проблему (что, где, насколько срочно) — Product, Version, Severity;
Assignee определяет Priority, Status, переводя баг по состояниям NEW -> ASSIGNED -> RESOLVED.
QA Contact определяет Status, переводя баг из RESOLVED в VERIFIED или REOPENED.

Если в инсталляции Bugzilla включены функции регистрации времени (например, параметр timetrackinggroup), то можно регистрировать предварительную оценку сложности задачи и с каждым комментарием свои трудозатраты, корректировать оценку оставшийся работы (См. Учет времени (Time tracking)).

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

Лента комментариев к багу, отсортированная по времени;
View Bug Activity - история изменения всех атрибутов бага.
Look for Bug in CVS, SVN, Git - ссылка на страницу ViewVC — выполняет поиск в CVS и Subversion - репозитариях ревизий файлов, в комментариях к которым указан номер этого бага. Страница результатов поиска содержит также ссылки на другие действия с файлами. Оставленная до поры, до времени ^+Old — ссылка на аналогичную страницу поиска в Bonsai в будущем будет удалена. См. интеграция с системами контроля версий.
Look for Bug in Wiki - перенаправляет на ассоциированную с багом статью Wiki см. Интеграция с Wiki.

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

В стандартной инсталляции для этого можно использовать страничку c адресом вида http://bugs.office.custis.ru/bugs/page.cgi?id=linkify.html

Клонирование бага

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

ссылка clone to other/same/int product на первом комментарии;
ссылка Clone This Bug внизу страницы (аналог clone to other product на первом комментарии).

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

В нашей инсталляции Bugzilla также можно клонировать в баг любой комментарий исходного бага ссылкой clone to other/same/int product на комментарии.

Полезности Bugzilla

Автоматические ссылки

Комментарии в Bugzilla разрешены только plain текстом с использованием некоторых HTML-тегов. Ссылки с помощью <A HREF=""> вставить не получится. Тем не менее, Bugzilla делает гиперссылки для определенного рода комментариев, например распознаются и гиперлинкуются основные типы URL:

«http://»,
«ftp://»,
«mailto:»,
почтовые адреса someone@somewhere.org.

Дополнительно гиперлинкуются ссылки на внутрибагзильные элементы (баги, комменты, вложения):

bug 12345
comment 7
bug 23456, comment 53
attachment 4321

Интеграция с системами контроля версий

Очень важно описать связь между багами (заданиями или сообщениями об ошибках) и производимым (исправляемым) разработчиком артефактом — программным кодом (включая документацию). В нашей Компании весь код (то есть практически все производимое разработчиком) находится в репозиториях принятых в Компании систем управления версиями CVS и Subversion и Git.

Наша инсталляция Bugzilla интегрирована с системой ViewVC, в которую оперативно загружается информация о всех правках в CVS- и Subversion-репозиториях Компании. Поэтому, если при работе над багом XXX ведутся правки файлов, находящихся под CVS или Subversion, при фиксации (выполнении commit) не нужно писать длинных комментариев, описывающих суть изменений, а достаточно указать номер бага. Например, выполнить

cvs commit -m "Bug 1234"

Комментарий можно вводить и через опции командной строки, и через редактор, см. ссылки на документацию в CVS, Subversion.

При соблюдении этого правила для каждого бага можно найти все commit'ы, в комментариях к которым указан номер этого бага, с помощью ссылки Look for Bug in CVS, SVN, Git на странице бага.

Ранее похожую функцию выполнял Bonsai, однако был сделан переход на ViewVC по причине поддержки не только системы контроля версий CVS, но также и Subversion последним. Посему ссылки Look for Bug in CVS, SVN, Git теперь ведут именно в ViewVC.

Интеграция с Wiki

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

В нашей инсталляции Bugzilla дополнительно к возможностям автоматических ссылок можно делать читаемые гипертекстовые ссылки на статьи (разделы статей) в CustisWiki, например:

wiki:Bugzilla#Автоматические_ссылки
wiki:[[Bugzilla#Автоматические ссылки]]

будет ссылаться на Bugzilla#Автоматические_ссылки.

Если при работе над багом требуется сделать документ-постановку задачи и/или провести его обсуждение, можно воспользоваться ссылкой Look for Bug in Wiki на странице бага и перейти к одноименной с багом статье Bug XXX для чтения/редактирования/обсуждения.

Рекомендуется после заведения статьи выполнить ее переименование (закладка move/переименовать) в более понятное название, например «Ошибка ORA-YYY при загрузке каталога (Bug XXX)», copy-paste атрибута Summary.

Таким образом, будет создана статья с смысловым заголовком и статья-перенаправление «Bug XXX».

Однако, стоит помнить, что в CustisWiki не стоит помещать конфиденциальную информацию, так как тут уже не действует система прав Bugzilla.

Учет времени (Time tracking)

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

Ведется учет следующих полей:

Orig. Est. - начальная оценка трудоемкости бага. Разумно использовать как априорную оценку трудоемкости. Хотя ее можно менять, лучше это делать реже, чтобы сохранился смысл априорной оценки, данной разработчиком или руководителем проекта;
Current Est.- текущая оценка трудоемкости бага. Вычислимое поле, является суммой Hours Worked и Hours Left;
Hours Worked- число затраченных часов. Только увеличивается с каждым редактированием;
Hours Left - осталось затраченных часов. Изначально выставляется, как разница Current Est. и Hours Worked, но будучи отредактированным, влияет на Current Est. Например, если считалось, что на баг надо затратить 5 часов, а после некоторой работы выяснилось, что затрачено 3 часа, а осталось еще 7, то текущая оценка меняется на 10 часов.
% Complete - процент завершенности. Вычислимое поле, равно Hours Worked/Current Est.
Gain - Выигрыш. Вычислимое поле, является разностью Orig. Est. и Current Est.
Deadline - крайний срок решения/выполнения бага.

Единица измерения — часы. Можно вводить дробные значения 1.5 = полтора часа.

Time Summary

Отчет Time Summary для выбранного списка багов показывает зарегистрированные трудозатраты за заданный период с группировкой по месяцам, с разбивкой по сотрудниками или багам.

Советы по использованию Bugzilla

В процессе использования Bugzilla было сделано много доработок. О них можно очень кратко прочитать здесь Bugzilla: Список доработок#Доработки 3.x

Поддерживайте целостность:
- Дублируйте содержимое Summary в первом комментарии,
- Указывайте корректные значения в полях или не указывать никаких. Например, не пишите строки «any», «нет», "-" и прочее в URL, если нет конкретного связанного с багом URL.

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

Сделана специальная доработка (Bug:15001 и Bug:53638, которая позволяет присоединить текстовое вложение к багу через буфер обмена, без создания файла, с одновременным добавлением комментария, фиксацией времени и изменением некоторых атрибутов бага. Таким образом, если Вы получили текстовое сообщение об ошибке с большим стеком, то надо не писать комментарий, а добавить вложение, где вставить это сообщение в текстовое окно вложения (переключив radio button на Enter text), а ниже написать комментарий с краткой формулировкой ошибки.

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

Не вкладывайте простые тестовые примеры (например HTML-файл, ссылающийся на CSS и картинку) как архив. Вместо этого загрузите перечисленные файлы в обратном порядке, и отредактируйте вкладываемый HTML-файл, чтобы он ссылался непосредственно на загруженные вложения. Bugzilla хранит и использует Content-Type для каждого вложения (например, text/html). Чтобы выгружать вложение с другим Content-Type (например, application/xhtml+xml), надо добавить CGI-параметр Content-type в URL, то есть &content-type=text/plain.

Комментирование

Если вы изменяете баг, добавляйте комментарий, только если вам действительно есть что сказать или если этого требует Bugzilla (для некоторых типов переходов). В противном случае, вы будете без нужды засыпать письмами связанных с багом пользователей. Например, люди могут настроить свой аккаунт (см. Field/recipient specific options), чтобы не получать извещений при событиях вида «Изменился CC List». Но если доброжелатель добавляя себя, добавит комментарий «Я, типа, себя добавил», это будет уже добавление комментария и обойдет вышеуказанный фильтр.

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

Конфликты

Если вы считаете, что отправленный вами баг некорректно помечен как DUPLICATE of another, задавайте вопросы-комментарии в вашем баге, а не в том, который считается багом-оригиналом. Смело добавляйте в CC List бага человека, который принял такое решение, если его нет.

Флаги

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

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

Чтобы установить флаг, выберите +, или - из выпадающего списка Flags. Значение этих символов зависит от флага? в качестве примера, установление флага review в + может означать, что баг или вложение одобрены, а в - — отклонены. Чтобы сбросить флаг, выберите в выпадающем списке пустое значение.

Чтобы сделать запрошенный флаг, установите флаг в ? и введите имя пользователя, у которого запрашиваете установку флага.

В нашей инсталляции Bugzilla есть доработка, позволяющая не вводить пользователей для запрашиваемых флагов вручную, а выбирать из списка связанных с багом пользователей (Reporter, Assignee, QA Contact, CC List).

Установленный флаг показывается на странице бага и странице edit attachment рядом с аббревиатурой установившего флаг пользователя. Например: Иван: review [ + ]. Аналогично показывается запрошенный флаг, только в скобках показывается имя пользователя, у которого запрошена установка флага, например Иван: review [ ? ] (Бибичев).

Отчеты и графики

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

Отчеты

Отчет представляет собой некий информационный срез о текущем состоянии базы зарегистрированных багов. Можно сделать отчет как обычным, HTML-табличным, так и графическим, с различными видами графиков: линейными, круговыми, гистограммы (line/pie/bar), и переключаться между этими режимами просмотра онлайн.

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

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

Или разработчик может выбрать все свои баги, распределив их по критичности и своей оценке приоритета, получив следующую таблицу, где каждая ячейка (например, (major,P2)=> 2) является гиперссылкой на выборку соответствующих багов (в данном случае, двух багов, у которых в дополнение к условиям общего запроса Severity=major, а Priority=P2):

            Priority
Severity       P2       P3     P4     P5   Total
 major         2        .       1     .     3
 normal        8        1       1     .     10
 minor         .        .       2     2     4
 trivial       .        1       .     .     1
 enhancement   .        .       1     1     2
 Total         10       2       5     3     20

От выборки багов можно снова перейти к таблице и продолжить детализацию далее (см. описание Summary report в списках багов.

После заполнения параметров и вызова Generate Report вы можете переключаться между форматами HTML, CSV, Bar, Line, Pie (формат Pie доступен, если вы определили только одну горизонтальную ось). Остальные интерфейсные элементы интуитивно понятны — можно изменять размер картинки, если текст наползает графику или слишком узкие столбцы гистограмм.

В нашей инсталляции Bugzilla кроме числа багов можно просматривать агрегированные временные параметры бага:

Remaining time;
Estimated time.

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

          Priority
Severity       P2      P3      P4      P5      Total
major          32      .       .       .       32
normal         47.5   184      .       .       231.5
minor          .       .       .       192     192
trivial        .       5       .       .       5
enhancement    .       .       30      3       33
Total          79.5   189      30      195     493.5

Динамические графики (Charts)

Динамические график (chart, чарт) — это просмотр эволюции состояния базы багов во времени.

В данный момент в Bugzilla есть две системы построения таких графиков — Old Charts и New Charts.

Old Charts — это старая, давно используемая система, она отображает только изменения статусов и решений багов для каждого продукта. Она более не поддерживается и не развивается, и будет вскоре исключена из системы. Развиваться будет система New Charts, которая позволяет отрисовывать все, что можно задать поисковым запросом.

Обе системы требуют, чтобы администратор настроил скрипт, собирающий данные.

Каждая отдельная линия в чарте представляется датасетом data set, которые упорядочены в категории и подкатегории. Категории/подкатегории автоматически определяются на основе отношений Продукт/Компонент (для всех продуктов и компонентов), но также можно определять и любые другие категории.

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

Датасеты не должны пересекаться по набору (Категория, Подкатегория, Имя) - даже приватные. Поэтому личные датасеты лучше заводить под Категорией со своим именем.

Создание Динамических графиков

Для создания динамического графика необходимо выбрать в списке требуемые датасеты и нажать Add To List. В списке List Of Data Sets To Plot вы можете задать название для каждого отображаемого датасета, также можно заказать суммирование подмножества выбранных датасетов (то есть просуммировать датасеты? представляющие баги в состоянии RESOLVED, VERIFIED и CLOSED для выбранного продукта, получив полное число исправленных багов). Ошибочно добавленный датасет можно исключить с помощью чекбокса и Remove. Если вы добавили более одного датасета, в списке автоматически появится линия Grand Total. Если она не нужна, ее можно удалить, как и любую другую линию.

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

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

По окончании настроек нажмите Chart This List для получения чарта.

Создание датасетов

Для создания нового датасета следуйте ссылке create a new data set на странице Create Chart. Используя стандартный интерфейс выбора определите нужную выборку, внизу страницы определите категорию, подкатегорию и имя для нового датасета.

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

Настройки пользователя

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

Настройки расположены на пяти вкладках: General preferences, Email preferences, Saved searches, Name and password, Permissoins. Рассмотрим подробнее каждую из них.

General preferences

Вкладка содержит простые настройки общеинтерфейсного плана.

В нашей инсталляции Bugzilla дополнительно включены настройки:

After changing a bug - по умолчанию, после правки бага Bugzilla перенаправляет на следующий баг в списке, однако большинство людей это смущает, и они путают следующий баг с предыдущим. Для борьбы с этим поведением и служит данная опция. Нужно выбрать Show the updated bug;
Remind me to track worktime for each comment - запрос затраченного времени, если пользователь из timetrackinggroup не заполнил (поставил 0) в Hours Worked при введении комментария;
Remind me to track worktime for new bug - требование введения трудозатрат от пользователя из timetrackinggroup при постановке каждого нового бага;
Remind me about flag requests - при вводе комментария пользователем, на которого поставлены флаги-запросы (флаги в состоянии ?, у которых requestee = этому пользователю) — будет проверять и переспрашивать, не желает ли пользователь изменить состояния флагов (ответил ли он своим комментарием на эти вопросы).

Email preferences

Эти настройки определяют когда и сколько писем будет вам прислать Bugzilla. Если вы хотите получать все письма — нажмите кнопку Enable All Mail, если не хотите получать письма от Bugzilla вообще — нажмите Disable All Mail.

Администратор Bugzilla может заблокировать получение почты пользователем через добавление имени пользователя в файл data/nomail. Такие меры применяются в исключительных случаях — например, для аккаунтов уволившихся сотрудников.

Раздел Global options содержит (пока?) только настройки извещений по флагам):

Email me when someone asks me to set a flag - уведомление о том, что вам адресован запрошенный флаг;
Email me when someone sets a flag I asked for - уведомление о том, что кто-то ответил (установил в + или -) на запрошенный вами флаг.

Раздел Field/recipient specific options содержит настройки для определения случаев, когда вы хотите получать письма от Bugzilla, и в каких отношениях с багом вы должны при этом находиться. Поставьте/уберите галочки в соответствующих клетках.

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

Reporter - вы указаны в поле Reporter;
Assignee - вы указаны в поле Assigned To;
QA Contact - вы указаны в поле QA Contact;
CCed - вы указаны в списке CC List.

Почту также можно фильтровать по различным заголовкам X-Bugzilla-Что-Нибудь, присутствующих во всех письмах от Bugzilla (см. [[#Дополнительные email-заголовки|Дополнительные email-заголовки).

По умолчанию Bugzilla рассылает почту вне зависимости от того, кто был автором изменения бага, и вы будете получать почту, даже если будете единственным лицом, связанным с багом. Если вы не хотите получать письма после своих изменений, поставьте галочки в строке but not when (overrides above): The change was made by me.

Если использовать более-менее вменяемый почтовый клиент, лучше разрешить получать почту и комментарии при своих изменениях, добавив правило «помечать письма содержащие 'xxx@company.com changed:' как прочтенные» (Вместо xxx@company.com разумеется, ваш логин). Установив локальный поисковик и проиндексировав почту, это даст возможность удобного полнотекстового поиска по всем комментариям связанных с вами багов.

Раздел User Watching содержит пользователей, следящих за вашим потоком извещений от Bugzilla.

Если вы введете список (разделенный запятыми) пользовательских аккаунтов (обычно совпадающих с email-адресами) в Users to watch, то будете получать копию всех писем, рассылаемых пользователю Bugzillой (с учетом настроек безопасности).

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

Не злоупотребляйте этой возможностью!

Saved searches

... добавить инфу ...

Name and password

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

Permissoins

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

Фильтрация писем от Bugzilla

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

Заголовки — это не subject, а внутренние заголовки письма, увидеть которые можно в свойствах письма или выбрав в почтовой программе пункт View Message Headers или подобный.

Список заголовков:

X-Bugzilla-Reason - отношение получателя к упомянутому багу: Assigned To (ответственный), Reporter (создатель бага), QA Contact (тестировщик), CC List (наблюдатель), Voter (голосовал за баг);
X-Bugzilla-Watch-Reason - то же, но каждое значение означает, что получатель наблюдает за пользователем, имеющим соответствующее отношение к упомянутому багу. Плюс есть ещё одно значение — GlobalWatcher, означающее, что пользователь получает всю почту по всем багам;
X-Bugzilla-Type - new (новый баг), changed (изменение) или request (изменение флагов);
X-Bugzilla-Who - логин (то есть, e-mail адрес) изменившего баг;
X-Bugzilla-Changed-Fields - список изменённых полей упомянутого бага;
X-Bugzilla-Added-Comments - количество добавленных комментариев (0 или более).

Также есть набор заголовков, имеющих значением значение соответствующего атрибута бага:

X-Bugzilla-Classification
X-Bugzilla-Product
X-Bugzilla-Component
X-Bugzilla-Status
X-Bugzilla-Priority
X-Bugzilla-Severity
X-Bugzilla-Assigned-To
X-Bugzilla-QA-Contact
X-Bugzilla-Target-Milestone
X-Bugzilla-Keywords

Примеры:

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

Решение: Заголовок X-Bugzilla-Added-Comments равен 0 и заголовок X-Bugzilla-Changed-Fields пуст.

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

Решение: В Outlook создать правило, которое будет перемещать письма, содержащие в заголовке "X-Bugzilla-Reason: Assigned-To" или "X-Bugzilla-Reason: CC Assigned-To" или "X-Bugzilla-Type: request" или "X-Bugzilla-Reason: Reporter", в нужную папку.

Просмотр Патчей

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

Просмотр и ревизия исправлений в Bugzilla часто затруднена из-за недостатка контекста, несоответствующих форматов и других сложностей. Patch Viewer это дополнение Bugzilla, предназначенное для улучшения контекста, интеграции с Bonsai, LXR, CVS.

Patch Viewer позволяет:

Просмотр исправлений с раскраской, в режиме side-by-side, а не интерпретация сырого содержимого исправления;
Просмотр разницы между двумя исправлениями;
Получение контекстной информации об исправлении;
Удобный просмотр исправления с возможностью скрывать/раскрывать разделы;
Ссылки на разделы исправления для обсуждения или ревизии;
Ссылки на Bonsai или LXR для определения ответственности;
Создает исправления в унифицированном diff-формате.

В нашей инсталляции Bugzilla мы не используем PatchViewer, так как есть гораздо более удобная система просмотра версионных репозиториев ViewVC (см. Интеграция с системами контроля версий).

Ссылки

Bugzilla в России; Bugzilla в Википедии; Bug Tracking системы (бесплатные).

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

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

Внимание! Данная статья выбрана для репликации в SMWiki.

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

Непрерывная интеграция

2013-01-15T12:36:56Z

IgorShatalkin:

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

Рынок ERP: рост в условиях турбулентности

2013-01-15T10:26:09Z

AlexandraVelyaninova:

Максим Михалев, наш директор по маркетингу и продажам, рассказал еженедельнику PC Week/RE о состоянии российского рынка ERP на начало 2012 года и наиболее актуальных задачах, которые решались компаниями с помощью ERP-систем в прошедшем году. Комментарии Максима опубликованы в обзоре «Рынок ERP: рост в условиях турбулентности» на сайте издания.

PC Week: Какой, по вашим оценкам, была в прошедшем году динамика российского рынка ERP в трех сегментах: крупные предприятия, предприятия среднего и малого бизнеса (СМБ) и госсектор? Что в этом отношении можно ожидать от года наступившего?

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

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

PC Week: Какие наиболее актуальные и востребованные заказчиками задачи решались предприятиями с помощью ERP-систем в прошедшем году? Ваш прогноз на нынешний год?

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

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

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

Летом 2011 года в магазинах торговой сети O’STIN была внедрена система «Розничный магазин Lite», разработанная CUSTIS. Новое ПО позволяет существенно упростить выбор торговых помещений и сократить затраты на автоматизацию сети в целом без ущерба для процессов продаж в магазинах и оперативного учета в центральном офисе. Это решение было запланировано еще в период активной оптимизации расходов и оказалось особенно актуально для розничной сети с большим количеством малоформатных магазинов.

PC Week: Как вы считаете, выйдут ли ERP-решения за пределы частного облака и каковы перспективы разделения ERP-функциональности в гибридных архитектурах между общедоступными и частными облаками?

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

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

Облачно-ориентированная ИТ-инфраструктура: возможности и проблемы управления сервисами в облаке

2013-01-11T15:53:54Z

AlexandraVelyaninova: /* Рискуем и/или выигрываем? */

В журнале Rational Enterprise Management (№5/2012) опубликована статья ведущего системного инженера Дмитрия Морозова, посвященная созданию облачно-ориентированной ИТ-инфраструктуры. Какие требования предъявляются к ИТ-инфраструктуре со стороны бизнеса? Каковы преимущества и риски перевода ИТ-систем в облака? Когда есть смысл создавать частное облако? Об этом — в статье «Облачно-ориентированная ИТ-инфраструктура: возможности и проблемы управления сервисами в облаке» на сайте и в бумажной версии журнала.

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

Доступ запрещён

2013-01-11T12:43:50Z

127.0.0.1:

MediaWiki:Hacl permission denied

WikiHelp:UML

2013-01-09T09:58:14Z

AndreyMoiseev:

{{#set: |HelpId=UML |HelpOrder=600 |ParentMenuId=AdvancedMarkup |HelpContent=Справка:UML |HelpDisplay=Диаграммы UML }}

[Исходная статья]

Можно автоматически рисовать UML-диаграммы классов по их текстовому описанию, причём с помощью двух расширений:

PlantUML — более удобный, чем UMLGraph, по собственному языку разметки.
UMLGraph — по близкому к описанию классов на языках типа Java/С#.

PlantUML

Полная справка по языку — Media:PlantUML Language Reference Guide.pdf.

Справка по PlantUML

Синтаксис вставки — просто

<uml>
 ...код...
</uml>

Пример графа:

Разметка

<uml>
title Основной цикл — получение агрегированных проводок
 
autonumber "<b>[0]"
 
note left of МСФО: 1.1
activate МСФО
МСФО -> Система: Запрос справочников
deactivate МСФО
 
note right of Система: 2.1
activate Система
Система -> МСФО: Возврат справочников
deactivate Система
note left of МСФО: 1.2
 
activate МСФО
МСФО -> Система: Запрос используемых аналитик
deactivate МСФО
note right of Система: 2.2
activate Система
Система -> МСФО: Возврат используемых аналитик
deactivate Система
note left of МСФО: 1.3
 
activate МСФО
МСФО -> Система: Запрос выгрузки/выгрузок
deactivate МСФО
note right of Система: 2.3
activate Система
Система -> МСФО: Возврат выгрузки/выгрузок
deactivate Система
note left of МСФО: 1.4
 
activate МСФО
МСФО -> Система: Результат выгрузки/выгрузок
deactivate МСФО
activate Система
note right of Система: 2.4
</uml>

UMLGraph

Диаграммы классов

/**
* @opt nodefontcolor "blue"  
*/
class Person {
        String Name;
}
 
class Employee extends Person {}
 
class Client extends Person {}

 
class Tyre {}
class Engine {}
class Body {}
 
/**
* @composed 1 - 4 Tyre
* @composed 1 - 1 Engine
* @composed 1 - 1 Body
*/
class Car {}

/**
 * @opt shape node
 * @note Located in the
 * machine room
 * @note Sun Blade 6048
 * @depend - - - MapLocation
 * @depend - - - DataMine
 */
class Server{}
 
/** @opt shape component */
class MapLocation {}
 
/** @opt shape component */
class DataMine {}
 
/**
 * CPU-munching
 * components that must
 * run on this server
 * @opt shape note
 * @opt commentname
 * @assoc - - - MapLocation
 * @assoc - - - DataMine
 */
class munchComment {}

Большой пример

Generalisation Relationships

Advanced Relationships

Relationships Inference

Schema

Element Visibility

Association Types

Real Example (Catalina Classes)

Class Stereotypes and Tagged Values

Fonts, Colors, Global and Local Options

Еще пример

Ссылки

http://umlgraph.org Automated Drawing of UML Diagrams

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

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

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Опросы и голосования

2013-01-09T09:54:36Z

AndreyMoiseev:

{{#set: |HelpId=Polls |HelpOrder=200 |ParentMenuId=Social |HelpContent=Справка:Опросы и голосования |HelpDisplay=Опросы и голосования }}

[Исходная статья]

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

Опросы бывают следующих основных типов:

Режимы

CHECKS

Возможность отметки любого предложенного варианта (по одному разу). Пример:

<poll>
Какие программы и системы, вы используете в повседневной работе:
[[{{SITENAME}}]]
[[Bugzilla]]
[[Bonsai]]
[[TeX]]
[[CVS]]
[[Oracle]]
[[Python]]
Erwin
Open Office
</poll>

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

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

POINTS

«POINTS N» — голосование с определенным (N) количеством голосов, которых можно распределить по предложенным вариантам.

Пример:

<poll>
POINTS 7
Распределите ваши симпатии по фирмам-производителям автомобилей:
TOYOTA 
NISSAN
ALFA-ROMEO
BETA-ROMEO
GAMMA-ROMEO
OPEL
VAZ
</poll>

Распределите ваши симпатии по фирмам-производителям автомобилей:

Вы можете использовать 7 голосов.

TOYOTA
NISSAN
ALFA-ROMEO
BETA-ROMEO
GAMMA-ROMEO
OPEL
VAZ

«Ключевая» строка в этом примере, задающая нужный режим — «POINTS 7».

Можно использовать ключевую строку «ALTERNATIVE» для задания режима «POINTS 1», то есть выбора только одного варианта из предложенных.

Авторизация

Опрос можно сделать авторизованным, то есть запретить голосование анонимным пользователям, которые учитываются по IP-адресам. Для этого используется ключевая строка «AUTHORIZED». Анонимные пользователи увидят только список вариантов и строку «вы должны войти в систему, чтобы участвовать в голосовании». Зарегистрированные пользователи CustisWiki увидят форму голосования и/или результаты.

Есть ещё более жёсткий вариант, полностью скрывающий и голосование, и варианты ответов от анонимных пользователей — «AUTHORIZED_DISPLAY».

<poll>
AUTHORIZED
ALTERNATIVE
Вам нравится работать в нашей компании?
Да
Нет
</poll>

Вам нравится работать в нашей компании?

Да
Нет

Вы должны войти в систему, чтобы участвовать в этом голосовании.

Ограничение по IP-адресам

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

Работа

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

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

Конец опроса

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

Тем не менее, существует опция «END_POLL YYYY-MM-DD», где YYYY-MM-DD — дата (YYYY — год, MM — месяц, DD — день), позволяющая автоматически закончить опрос, начиная с даты YYYY-MM-DD. То есть, начиная с этой даты, все пользователи, вне зависимости от того, голосовали они или нет, увидят только результаты и не увидят формы голосования.

Скрытие результатов

Специально для спецагентов и «секретных» опросов существует опция «HIDE_RESULTS», позволяющая скрывать результаты голосования от рядовых пользователей, по крайней мере, до конца опроса. Проголосовавшие пользователи увидят только сообщение «Вы уже проголосовали, всего проголосовало столько-то человек, а результаты будут (или не будут) доступны после даты YYYY-MM-DD». Результаты не будут показаны никогда, если опрос не имеет конца, то есть, если не указана опция END_POLL. В базе данных они, естественно, будут сохранены, и могут быть извлечены оттуда любым человеком, имеющим прямой доступ к БД.

Разрешение переголосования

Чтобы разрешить отозвать свой голос и проголосовать заново, нужно добавить опцию «REVOTE», она же кому как больше нравится — ALLOW_REVOTE, ALLOW_RECALL. Если добавить эту опцию после создания опроса, могут быть потеряны ранее отданные голоса.

Нецелостный («тупой», «небезопасный») режим

Опция UNSAFE ID=УникальнаяСтрока даёт вашему голосованию идентификатор, равный этой уникальной строке, после чего в голосование можно добавлять/удалять вопросы, менять заголовок и опции. Голосовалка будет вести себя тупо — считать количества по НОМЕРАМ ответов и показывать их всегда для этого голосования. То есть если вы удалите ответ из середины, все голоса за ответы, стоящие ниже него, собьются. Также всегда любой может подсмотреть результаты небезопасного голосования, даже если они скрыты, добавив соответствующую опцию и даже не сохраняя страницу, а делая предпросмотр. В то же время путём указания UNSAFE ID=ID реального (безопасного) голосования подсмотреть его результаты невозможно.

Привязка к названию страницы

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

Открытые голосования

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

Также есть опция OPEN_RESULTS, которая совмещает форму голосования с результатами и показывает их всем, даже ещё не проголосовавшим, пользователям.

Email-оповещение

Для голосования можно указать опцию VOTES_TO_EMAIL=N (N — неотрицательное число). Если она указана, то при наборе как минимум N голосов все пользователи, следящие за страницей с голосованием (обычное вики-слежение, или «наблюдение»), будут получать результаты голосования на свои email-адреса (адреса для этого должны быть подтверждены). Смысл такого слежения — асинхронность: забросил голосовалку, следишь за страницей и ждёшь, пока начнёт работать закон больших чисел, то есть результаты голосования начнут что-то значить.

Синтаксис

Синтаксис опросов построчный (то есть каждый элемент — строка), и представлен на этом графе. В вопросах и вариантах ответа можно ограниченно использовать вики-разметку (все, что можно выразить одной строчкой).

[svg]

Внимание! Данная статья выбрана для репликации в SMWiki.

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

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

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:RSS

2013-01-09T09:50:53Z

AndreyMoiseev:

{{#set: |HelpId=RSS |HelpOrder=200 |ParentMenuId=AdvancedOther |HelpContent=ListFeed_(расширение_MediaWiki) |HelpDisplay=RSS }}

[Исходная статья]

ListFeed — расширение MediaWiki, позволяющее генерировать простые RSS-ленты из стандартных списков MediaWiki (нумерованных «#» и маркированных «*»).

Инструкции по установке и исходные коды можно увидеть на домашней странице расширения.

С помощью этого расширения практически любой список можно превратить в RSS-ленту.

Расширение добавляет два новых тега — <listfeed> и <endlistfeed />, а также функцию парсера {{#listfeedurl:Feed Name}}, которая возвращает URL RSS-ленты, сгенерированной расширением из списка с заданным именем. Расширение позволяет легко превратить любой маркированный или нумерованный Wiki-список в RSS-ленты, которая автоматически обновляется при обновлении статьи.

Каждый элемент списка становится отдельной записью ленты.

Заголовком записи становится первая строка текста элемента списка.
Текстом записи — всё остальное, если оно присутствует, и просто весь текст элемента списка, если нет.
Дата записи разбирается в соответствии с заданным регулярным выражением (см. ниже) и вырезается из заголовка.
Ссылкой записи становится первая ссылка в тексте, за исключением даты, так как в дате может присутствовать ссылка на автора, например, если используются стандартные подписи (~~~~). Если ссылок в тексте нет, используется ссылка на статью с уникальным якорем (anchor) для идентификации записи.
Автором записи становится первая ссылка в пространство имён [[Участник:]] из текста элемента списка, либо автор последней ревизии статьи.

Ленты идентифицируются по именам (<listfeed name="ИМЯ_ЛЕНТЫ">) и помещаются в один каталог, поэтому в пределах одной Wiki-системы две ленты с одинаковыми именами будут перезаписывать друг друга при каждом обновлении страницы. Описанием ленты служит любой Wiki-код, заключённый в тег <listfeed> — он преобразуется в HTML и включается в RSS-элемент <about>.

Чтобы начать использовать ListFeed, добавьте тег <listfeed> перед вашим списком:

<listfeed name="ИМЯ_ЛЕНТЫ" [ОПЦИИ]>
ОПИСАНИЕ_ЛЕНТЫ
</listfeed>

И тег <endlistfeed> после списка:

<endlistfeed />

Чтобы вставить ссылку на ленту в текст статьи, нужно использовать функцию парсера:

{{#listfeedurl:ИМЯ_ЛЕНТЫ}}

На данный момент доступны две опции, связанные с разбором дат элементов ленты.

Опция date

<listfeed date="ВЫРАЖЕНИЕ">.

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

^(?:[^:]+|<[^<>]*>)*%H:%M(?::%S)?,\s*%d\s+%b\s+%Y(?:\s*\(UTC\))?(?:\s*:?)

ВЫРАЖЕНИЕ похоже на обычные Perl-совместимые регулярные выражения, однако, кроме стандартных инструкций, включаемых в регулярные выражения, оно также может содержать большинство strftime(3)-подобных подстановок (см. ниже полный список поддерживаемых подстановок) и, таким образом, является как бы «обратной функцией» к strftime(3).

На данный момент поддерживаются следующие подстановки strftime:

%Y	год (4 цифры)
%y	год (2 цифры)
%C	век (2 цифры), может использоваться вместе с %y, по умолчанию выбирается текущий век, если выделенный год и текущий год лежат в одной половине века, и предыдущий/следующий, если в разных
%m	месяц (2 цифры, от 01 до 12)
%b / %B	имя месяца — либо полное (Январь, Января, January), либо сокращённое (Янв, Jan)
%d	день месяца (2 цифры)
%e	день месяца (1 или 2 цифры)
%H / %h	часы
%M	минуты
%S	секунды
%s	UNIX время — количество секунд, прошедших с начала Эпохи UNIX (1970-01-01 00:00:00)
%%	символ %

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

Опция headingdate

<listfeed headingdate="ВЫРАЖЕНИЕ">.

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

<listfeed name="News of extension" date="^%b %d:\s*" headingdate="%Y" />
= 2010 news =
* Jan 13: New version of ListFeed.
* Jan 01: Happy New Year!
= 2009 news =
* Dec 17: ...
* ...
<endlistfeed />

В данном случае даты не могут быть взяты целиком из каждого элемента, однако, год каждой даты со всей очевидностью присутствует в заголовке, поэтому и требуется разбирать его тоже. Для приведённого примера, выражение headingdate="%Y" абсолютно корректно.

Пример

<listfeed name="Новости CustisWiki">
Новости CustisWiki - важные статьи, голосования, новости системы
</listfeed>
* [[Участник:EvgeniaUdalova|Евгения Удалова]] 09:00, 5 октября 2009: Опрос ДМС 2009 завершён! Результаты можно посмотреть  [[Опрос_ДМС_2009| здесь]].
* [[Участник:MaksTsepkov|Макс Цепков]] 05:38, 26 сентября 2009 (UTC) Чтобы долго не искать - ссылки на блоги и rss:
*: [[Blog:Володя Рахтеенко]]
*: [[Blog:TechTools/Новости наших Wiki-систем: Блоги, черновики, интеграция с Subversion]] [[FeedOnFeeds]]
*: [[Служебная:Wikilog]] - общая лента блогов и замечание: когда ищите по wiki из панели слева, поиск в блогах отключен, надо включать галочку на результатах поиска.
<endlistfeed />

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

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

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Быстрое создание статей по шаблону

2013-01-09T08:40:23Z

AndreyMoiseev:

{{#set: |HelpId=ArticleByTemplate |HelpOrder=100 |ParentMenuId=Templates |HelpContent=Быстрое создание статей по шаблону |HelpDisplay=Создание статьи по шаблону }}

[Исходная статья]

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

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

«Создать статью в данной категории».

См. например, Категория:Тест-кейсы_(Bugzilla).

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

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Магические слова

2013-01-09T08:37:49Z

AndreyMoiseev:

{{#set: |HelpId=MagicWords |HelpOrder=1000 |ParentMenuId=AdvancedMarkup |HelpContent=Справка:Магические слова |HelpDisplay=Магические слова }}

[Исходная статья]

Приведет список магических слов, т. е. специальных подстановок, или модификаторов поведения CustisWiki

#redirect

Перенаправление на другую страницу — См. Help:Перенаправления.

NOTOC

Подавляет генерацию «содержания».

FORCETOC

Форсирует генерацию «содержания».

NOEDITSECTION

Скрыть ссылки на редактирование разделов.

START

Ничего не делает.

CURRENTMONTH

Переменная:

CURRENTMONTHNAME

Переменная:

июль

CURRENTDAY

Переменная:

CURRENTDAYNAME

Переменная:

пятница

CURRENTYEAR

Переменная:

2026

CURRENTTIME

Переменная:

21:09

NUMBEROFARTICLES

Переменная:

1489

CURRENTMONTHNAMEGEN

Переменная:

июля

PAGENAME

Переменная:

WikiHelp:Магические слова

PAGENAMEE

Переменная:

WikiHelp:%D0%9C%D0%B0%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D1%81%D0%BB%D0%BE%D0%B2%D0%B0

NAMESPACE

Переменная:

MSG:

Модификатор шаблонных подстановок — переданное имя считается шаблоном, даже, если есть такое же магическое слово. См. также Help:Шаблоны.

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

SUBST:

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

Bug:{{{1}}}

См. также Help:Шаблоны.

MSGNW:

Модификатор шаблонных подстановок — при его использовании, раскрывается только первый уровень, т. е. текст подставляемого шаблона подставляется без раскрытия (и дальнейшей обработки). Например:

{{MSGNW:Bug}}

даст <noinclude> <templatedata> { "params": { "1": { "label": "Номер бага", "required": true, "suggested": true }, "2": { "label": "Заголовок" } }, "description": "Ссылка на баг в Bugzilla" } </templatedata> Использовать так: <pre> {{Bug|Номер бага|(опционально) заголовок}} </pre> ----- См. также: * [[:Template:Attachment|Ссылка на вложение]] * [[:Template:BugInfo|Маленький информер по багу]] * [[:Template:BugInformer|Большой информер по багу]] * [[:Template:BugComment|Ссылка на комментарий в баге в Bugzilla]] * [[:Template:Bz-embed|Встраивание списка багов из Bugzilla (с учётом прав доступа)]] {{replicate-from-custiswiki-to-all}}</noinclude><includeonly>[http://bugs.office.custis.ru/bugs/show_bug.cgi?id={{{1|}}} {{#if:{{{2|}}}|{{{2}}}|Bug:{{{1|}}}}}]</includeonly>

См. также Help:Шаблоны.

END

Включить в текст статьи завершающие ее пустые (состоящие из пробелов или табуляций) строки.

thumbnail

Модификатор картинок — см. Help:Изображения.

right

Модификатор картинок — см. Help:Изображения.

left

Модификатор картинок — см. Help:Изображения.

none

Модификатор картинок — см. Help:Изображения.

27px

Модификатор картинок — см. Help:Изображения.

center

Модификатор картинок — см. Help:Изображения.

framed

Модификатор картинок — см. Help:Изображения.

SITENAME

Переменная:

CustisWiki

NS:

Специальный шаблон: подставляет имя неймспейса по его номеру.

{{NS:1}}
{{NS:4}}
{{NS:8}}

Обсуждение CustisWiki MediaWiki

LOCALURL:

Специальный шаблон: получает URL заданной страницы (возможно с учетом ссылки на отдельную секцию или команду редактирования).

{{localurl:Help:Магические слова|section=0}}

дает /index.php?title=%D0%A1%D0%BF%D1%80%D0%B0%D0%B2%D0%BA%D0%B0:%D0%9C%D0%B0%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D1%81%D0%BB%D0%BE%D0%B2%D0%B0&section=0

LOCALURLE:

Специальный шаблон: получает URL (кодированный) заданной страницы (возможно с учетом ссылки на отдельную секцию или команду редактирования).

{{localurl:Help:Магические слова|section=0}}

дает /index.php?title=%D0%A1%D0%BF%D1%80%D0%B0%D0%B2%D0%BA%D0%B0:%D0%9C%D0%B0%D0%B3%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D1%81%D0%BB%D0%BE%D0%B2%D0%B0&section=0

SERVER

Переменная:

https://lib.custis.ru

CURRENTWEEK

Переменная:

CURRENTDOW

Переменная:

<enableheadshift>

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

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

Внимание! Данная статья выбрана для репликации в SMWiki.

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

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}

WikiHelp:Шаблоны

2013-01-09T08:37:00Z

AndreyMoiseev:

{{#set: |HelpId=Templates |HelpOrder=800 |ParentMenuId=AdvancedMarkup |HelpContent=Справка:Шаблоны |HelpDisplay=Шаблоны }}

[Исходная статья]

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

Общая информация

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

Для того, чтобы включить статью «Template:name», нужно использовать следующий синтаксис (так называемый тэг шаблона) {{name}}. Тогда при показе статьи будет подставлено содержимое ссылаемого шаблона. Терминологически, этот процесс можно также называть

вызовом шаблона;
ccылкой на шаблон;
включением шаблона;
использованием шаблона; — в любом из перечисленных вариантов, речь идет об одном и том же.

Если страница «Template:name» еще не существует, то {{name}} будет работать как [[Template:name]], т. е. как ссылка на несуществующую статью, которую можно редактировать. Таким образом, шаблоны также удобно заводить, сначала сделав на него ссылку, а затем проследовав по ней.

Если статья name уже существует в обычном (не шаблонном) пространстве имен, или начинается с двоеточия (что означает ссылку на основное пространство имен), то ссылка не будет автоматически направлятся в шаблонное пространство имен «Template:». Таким образом, любую страницу можно использовать как шаблон. (Примечание: если вызывать так картинку или категорию — то будет подставлена описательная часть картинки и категории соответственно). Таким образом удобно

экспериментировать с шаблонами (не залезая в пространство шаблонов);
«вытаскивать» подписи и описания картинок;
изготавливать специальные составные статьи (например для печати).

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

Возможно также рекурсивное включение.

Переменные шаблона вычисляются после вставки шаблона в «вызывающую» статью, т. е. если в шаблоне содержится подстановка {{PAGENAME}}, то она будет развернута в имя вызывающей статьи, а не имя шаблона.

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

Параметры

Параметры шаблона могут быть поименованные или пронумерованные. Синтаксис использования может быть

{{templatename|parname1=parvalue1|parname2=parvalue2}}, тогда в теле шаблона надо ссылаться на {{{parname}}};
{{templatename|parvalue1|parvalue2}} тогда в теле шаблона нужно использовать {{{1}}}, {{{2}}}.

Лишние (не используемые в теле шаблона) параметры игнорируются. Имена параметров чувствительны к регистру, пробелы, подчеркивание и остальные символы не из набора [a-z\-A-Z0-9] недопустимы.

Обратите внимание на тройные фигурные скобки при использовании параметров!

Т.е. механизм шаблонов выполняет два типа подстановок:

вызов шаблона (двойные фигурные скобки) заменяется содержимым шаблона;
параметры шаблона (тройные фигурные скобки) заменяются параметрами шаблона.

Параметром шаблона может быть ссылка на другую статью. Пусть например у нас есть Шаблон:

   Начало {{{1}}} Конец.

Тогда

   {{Шаблон| [[Main_Page|Главная страница]]}}

будет развернуто в

Начало Главная страница Конец.

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

Заметим, что вызов {{Шаблон||a}} делает первый параметр определенным, но равным пустой строке. Если нужно задать второй параметр, не определяя первый, то нужно использовать вызов {{Шаблон||2=a}}. Этот синтаксис нужно использовать также, когда параметр вызова содержит знак "=", например "a=b", т.е. {{Шаблон|a=b|c}}, не определит параметр "1", зато определит параметр "a", зато {{Шаблон|1=a=b|2=c}} сделает все как надо.

Просмотр содержимого шаблона

Чтобы правильно увидеть содержимое шаблона, нужно смотреть на шаблон в режиме редактирования, т. к. некоторые подстановки, типа {{PAGENAME}}, могут раскрыться.

msgnw

Для показа содержимого шаблона (без wiki-интерпретации) можно использовать кодовый «волшебный» префикс u «msgnw:». Т.е. {{en}} и {{msgnw:en}} будут показаны как Шаблон:En и [[:Шаблон:En]] соответственно.

Ссылка на редактирование шаблона

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

Ограничения и возможности

Использование вложенных двойных или тройных фигурных скобок внутри двойных вложенных скобок

Не получиться вызывать шаблоны в зависимости от содержимого других шаблонов. Допустим, у нас есть шаблон «tctc» с содержимым «tc», и шаблон «tc» с содержимым «Ура».

Тогда вызов {{{{tctc}}}} даст текст {{{{tctc}}}}, а не «Ура».

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

Тэг категории в шаблоне. Проблема с кэшированием

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

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

Кэширование

Правка шаблона автоматически сбрасывает кэширование всех статей, напрямую использующих этот шаблон. Однако в случае с косвенными зависимостями (шаблоны зависящие от параметров и т. п.), внутренний кэш системы не сбрасывается и стандартный «Refresh» броузера может не помочь. В таких случаях используйте «action=purge», т. е. вызывайте URL типа https://lib.custis.ru/index.php?title=CustisWiki&action=purge

subst

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

Например «timestamp»:

{{subst:CURRENTDAY}} {{subst:CURRENTMONTHNAME}} {{subst:CURRENTYEAR}}, {{subst:CURRENTTIME}} (UTC)

подставится при сохранении, как:

3 March 2005, 16:56 (UTC)

Альтернатива subst

Используйте {{..}}, затем, в окне «preview», вытащите результат и замените исходные {{..}}.
Аналогично можно использовать msgnw.

Перенаправления

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

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

Заголовок страницы-результата есть имя исходной страницы, а не включаемой страницы.
Вся функциональность, (редактирование, обсуждение, watch-list, …) относится к включающей странице, и ничего (если не смотреть код) не связывает ее с включаемой страницей.
Включающая страница лежит в тех же категориях, что и включаемая.
Работают «двойные перенаправления» основанные на включении.

Ссылки на шаблон

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

История изменений для страниц содержащих шаблоны

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

Функции парсера

В CustisWiki установлено расширение ParserFunctions, позволяющее выполнить нетривиальное препроцессирование разметки.

Более подробно см. RuPedia:Википедия:Функции парсера.

Ссылки

Наши Шаблоны

<noinclude> и <includeonly>

Текст между <noinclude> и </noinclude> включается только когда шаблон не включен в статью. Наоборот, includeonly работает только когда шаблон включен в другую статью. Применение - категории, распространяющиеся только на шаблон или только на его включение; оглавление и титульный лист, которые должно уйти при включении во композитную статью и т.п.

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

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

{{#ask: ParentMenuId::Top

?HelpId

?HelpOrder

?ParentMenuId

?HelpDisplay

?HelpContent

?#=Link

sort=HelpOrder

format=template

named args=yes

template=WikiHelp/SideMenu/TopLevel

}}