Воркфлоу

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

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

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

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

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

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

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

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

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

Какие же проблемы мы вскрыли в последнее время:

  • часто задачи в basecamp в итоге просто полностью дублируют задачи в github.issues. С одной стороны это последствие было очевидно, с другой — к сожалению, не сразу. Процесс можно автоматизировать, но при любом раскладе он требует мониторинга и человеческого контроля. Т.е. в целом получаем лишнюю работу.
  • клиент часто не видит часть задач, комментариев и обсуждений. Проще на примерах. Менеджер находит логическую нестыковку в функционале проекта, ставит задачу на github, разработчик делает. Все прошло мимо заказчика. Хорошо, если за период были сделаны задачи по договоренности в basecamp. Но если нет, то информация о том, на что было потрачено время дойдет до клиента только на регулярном созвоне/встрече.
  • разработчик не видит общей картины по своим задачам. Да github позволяет смотреть свои задачи по всем проектам, но из-за лагов в синхронизации что-то может быть упущено. Кстати, тут еще вступают в игру исключения: единичные проекты у нас ведутся, например, только на github (клиент достаточно компетентен) или вообще в asana заказчика (так как наша работа — лишь часть общего проекта).
  • плохо понятны приоритеты по задачам. Понятно, что приоритеты такая вещь, которая на постоянство не претендует, поэтому тут без части управления не обойтись. Но иметь возможность сквозной приоритизации задач между проектами хочется.
  • менеджер или управляющий всей фирмы иногда не видят всей картины по загрузке в целом, что затрудняет планирование. Да, мы используем дополнительные инструменты, отслеживаем, закладываем, предугадываем и рискуем, но опять же — могло бы быть лучше.

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

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

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

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

Сначала общие принципы:

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

Теперь ближе к практике:

  • система ведения по крайней мере в рамках одного проекта должна быть одна, без разделения на «загончики» для клиента и разработчиков
  • маловероятно, что всем клиентам одинаково удобна будет одна система, что позволило бы использовать ее и для крупного планирования, но к этому можно стремиться
  • сам процесс вне зависимости от используемого инструмента для ведения задач более менее одинаков и как правило может быть понятно настроен
  • работа должна разбиваться на итерации. Идеально, если это будет одна неделя, максимум — две.
  • в рамках итерации есть обязательные точки коммуникации (созвон/встреча), в которых задействована все участники проекта:
    • планирование задач на неделю — команда формирует список задач на неделю
    • обзор результатов работы за неделю — исполнители отчитываются о результатах, команда обсуждает, отмечаются успехи, неудачи
    • ежедневные статусы — очень короткие встречи/созвоны/чаты, нацеленные на формирование плана на день и разрешения блокирующих вопросов
  • неделя как период для детального планирования является максимальным интервалом
  • при этом, конечно, планирование (roadmap) проекта на более долгосрочный период должно присутствовать
  • в течение итерации коммуникации не прекращаются, но концентрируются вокруг выбранных на неделю задач (комментарии, сообщения о готовности, обратная связь)
  • все задачи проекта изначально попадают в общий inbox/backlog (он может быть разбит на какие-то подсистемы, блоки, подпроекты)
  • крайне нежелательно в ходе итерации менять ее состав. Но эти случаи предусмотрены на данный момент в двух ситуациях:
    • критичный баг — должен быть поправлен как можно быстрее
    • критичный функционал, укладывающийся по времени в рамки итерации — таковой должен являться критичным именно с точки зрения бизнес-ценности в проекте. Решения об изменении состава итерации обязательно подкреплять обоснованием ценности, которое не должно состоять только из «потому что я так хочу»
  • задача в рамках итерации проходит несколько состояний (конкретный состав может отличаться от проекта к проекту, но принцип одинаков):
    • запланирована на неделю
    • в работе (in progress)
    • code review
    • тестирование на staging’е (демонстрация на тестовом сервере)
    • обратная связь (задействован менеджер со стороны исполнителя и представитель заказчика)
    • готова к релизу (либо заливается сразу в production, либо ожидает остальных запланированных на неделю)
    • залита в production (попала в релиз)
  • в зависимости от обратной связи статус задачи может перейти обратно на стадию «в работе»
  • со стороны заказчика обязательно должен быть один (это важно) человек с правом окончательного решения, который по результатам решает, пойдет задача в релиз или отправится на доработку (или даже на следующую итерацию)
  • задачи должны быть сформированы таким образом, чтобы всем было понятно условия ее готовности (definition of done, SMART)
  • задача считается окончательно выполненной только когда попадает в production
  • разработчик задействован на всех этапах жизни задачи
  • менеджер не должен выступать тестировщиком результатов разработчика
  • менеджер отвечает за соблюдение договоренностей, настройку коммуникаций, решение проблем, формулировку задач

Последствия:

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

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

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

Конечно, вся схема не взята чистым образом с потолка. При изучении вопроса, немало интернетов было перерыто в поисках священного Грааля. И вот пара из достойных находок, которые хорошо легли на мой мысленный процесс:

Windows Workflow Foundation (WF)

Предыдущая30313233343536373839404142434445Следующая

Windows Workflow Foundation (WF*) впервые была представлена в версии .NET Framework 3.0, но теперь подверглась основательной перестройке, в результате чего многие разработчики теперь найдут её гораздо более полезной.

В ней можно обнаружить, что в Visual Studio 2010 значительно улучшены средства работы с WF, и создавать собственные рабочие потоки стало гораздо удобней. Также можно найти новые средства управления потоком, класс Flowchart, а также ряд новых действий, таких как DoWhile, ForEach и ParallelForEach.

 

ПРИМЕЧАНИЕ: Windows Workflow Foundation (WF) представляет собой технологию корпорации Microsoft для определения, выполнения и управления рабочими процессами (англ. workflow). Данная технология входит в состав .NET Framework 3.0, который изначально установлен в Windows Vista и может быть установлен в Windows 2003 Server и Windows XP SP2. WF ориентирована на визуальное программирование и использует декларативную модель программирования.

WF поддерживается в Visual Studio 2005 в виде расширения (add-on), в состав которого входит визуальный дизайнер процессов и визуальный отладчик, позволяющий отладить созданный процесс. В Visual Studio 2008/2010/11 Beta эта функциональность входит изначально.

 

При помощи WF могут быть описаны три типа процессов:

  • последовательный процесс (Sequential Workflow) — переход от одного шага в другой без возвратов обратно;
  • конечный автомат (State-Machine Workflow) — переход из одного состояния в другое, возможны и произвольные возвраты в предыдущие состояния;
  • процесс, управляемый правилами (Rules-driven Workflow) — частный случай последовательного процесса, в котором переход на следующий шаг определяется набором правил.

Основы работы со средой разработки Visual Studio 2010

Основы работы со средой разработки Visual Studio 2010

 

Профессиональные разработчики программного обеспечения .NET наверняка располагают самым серьезным в этой сфере продуктом производства Microsoft, который называется Microsoft Visual Studio 2010 и доступен по ссылке: Visual Studio | MSDN (http://msdn.microsoft.com/ru-ru/vstudio). Этот продукт представляет собой самую функционально насыщенную и наиболее приспособленную под использование на предприятиях IDE-среду. Такая мощь, несомненно, имеет свою цену, которая варьируется в зависимости от версии Visual Studio 2010. Как не трудно догадаться, каждая версия поставляется со своим уникальным набором функциональных возможностей. Однако, корпорация предоставляет некоторые варианты версий бесплатно для школьников, студентов и аспирантов учебных заведений России по программе Microsoft DreamSpark.

Visual Studio 2010 представляет собой полностью интегрированную среду разработки(IDE). Она спроектирована таким образом, чтобы делать процесс написания кода, его отладки и компиляции в сборку для поставки конечным потребителям как можно более простым. На практике это означает, что Visual Studio является очень сложным приложением с многодокументным интерфейсом, в котором можно делать практически все, что касается разработки кода. Ниже перечислены основные возможности Visual Studio:

1. Текстовый редактор.

С помощью этого редактора можно подготавливать тексты программ на языке С# (а также Visual Basic 2010, Visual С++ 2010 и Visual F# 2010). Текстовый редактор обладает довольно мощными возможностями. Например, при вводе текста программы он автоматически компонует его на странице, создавая между строками необходимые отступы, выравнивая открывающие и закрывающие фигурные скобки блоков кода и выделяя ключевые слова цветом. Кроме того, по мере ввода кода он выполняет его проверку на предмет синтаксических ошибок и подчеркивает фрагменты, которые будут вызывать ошибки при компиляции, что также называется отладкой на стадии проектирования. В редакторе реализовано средство IntelliSense, которое обеспечивает автоматическое отображение имён классов, полей или методов при начале их ввода, а также списки параметров, которые поддерживают все доступные перегруженные версии методов при начале ввода параметров для методов.

2. Визуальный редактор форм.

Этот редактор позволяет размещать желаемые элементы управления для пользовательского интерфейса и доступа к данным в проекте, a Visual Studio затем автоматически добавляет в исходные файлы код на языке С#, который необходим для создания экземпляров этих элементов в проекте. Это возможно потому, что все элементы управления в .NET представляют собой экземпляры определённых базовых классов.

3. Вспомогательные окна.

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

4. Возможность компиляции прямо в среде разработки.

Вместо того чтобы выполнять компиляцию проекта, запуская компилятор С# из командной строки, можно выбрать соответствующий пункт меню в среде разработки. Visual Studio самостоятельно вызывает компилятор и передаёт ему все необходимые параметры командной строки, указывающие, на какие сборки должен ссылаться код и какой вид должна иметь сборка на выходе (например, исполняемый файл или библиотека *.dll). При желании Visual Studio может также автоматически запускать скомпилированный исполняемый файл на выполнение, позволяя проверить его работу.

5. Интегрированный отладчик.

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

6. Доступ к другим программам.

Visual Studio предоставляет доступ к целому ряду других утилит, которые позволяют просматривать и изменять различные аспекты компьютера или сети, не покидая среды разработки. Благодаря этим инструментам, можно просматривать выполняющиеся службы и активные соединения с базами данных, заглядывать в таблицы на сервере Microsoft SQL Server и даже посещать веб-сайты с использованием окна Internet Explorer.

7. Интегрированная справочная система MSDN.

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

Также Visual Studio 2010 содержит графические редакторы и конструкторы XML, обеспечивает поддержку разработки программ Windows, ориентированных на мобильные устройства, поддержку разработки программ Microsoft Office и Windows Workflow Foundation, содержит встроенную поддержку рефракторинга кода и инструменты визуального конструирования классов.

Создание проекта в среде разработки Visual Studio 2010

Создание проекта в среде разработки Visual Studio 2010

 

Создание нового проекта

 

После установки среды разработки Visual Studio 2010 можно приступать к созданию первого проекта. В Visual Studio редко когда требуется начинать с пустого файла и добавления в него кода С#. Разумеется, возможность создания пустого проекта приложения существует. Это нужно, если действительно возникла потребность в написании кода с нуля, либо при создании решения, которое должно содержать в себе несколько проектов.

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

 

Для получения окна Создать проект необходимо запустить среду разработки Visual Studio 2010, откроется Начальная страница:

 

Рис. 1. 1. Начальная страница Visual Studio 2010 Professional (русская версия)

 

Создаём пустой проект, для этого выполним последовательно: Файл -> Создать -> Проект… (также можно просто нажать сочетание клавиш Ctrl+Shift+N или пункт «Создать проект…» на Начальной странице). В открывшемся окне в левом списке ищем Последние шаблоны, далее жмём на Установленные шаблоны и далее на Visual C#:ъ. Откроется окно «Создать проект»:

 

Рис.

Управление бизнес-процессами на основе технологии Workflow

1. 1. Окно создания нового проекта

 

Выберем Консольное приложение, укажем Имя проекта, и Расположение (где создавать каталог проекта) и нажмём ОК.

 

Как можно увидеть на рисунке выше, в Visual Studio 2010 поддерживается возможность выбора версии .NET Framework (2.0, 3.x или 4), для которой должно создаваться приложение, с помощью раскрывающегося списка, отображаемого в правом верхнем углу диалогового окна Создать проект.

Предыдущая30313233343536373839404142434445Следующая



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

До недавнего времени оно могло выражаться в том, что на смену одним технологиям приходили другие. Но часто они приносили временное преимущество перед конкурентами, способное лишь на короткий срок изменить ситуацию. Компании оказываются в собственной ловушке: с одной стороны, на внедрение новейших технологий тратится значительная часть средств, с другой — большинство из них приносит лишь временный результат. В этом случае затраты часто не успевают окупить себя, и вместо ожидаемой прибыли компания несет убытки. Может быть, мы просто не умеем правильно пользоваться новыми технологиями? Как известно, существует две основных организационных структуры управления — вертикальная и горизонтальная. Самая привычная для нас, вертикальная организация отличается многоступенчатой иерархией, большим количеством визирующих органов, продолжительным временем принятия решения и нежеланием меняться. Горизонтальная организация характеризуется неразветвленной иерархией управления и может быстро откликаться на определенные решения. Только горизонтальные организации способны улавливать малейшие изменения внешней среды и адекватно реагировать на них, а значит именно они способны выжить в сегодняшней ситуации. Однако решить проблему путем простой ликвидации иерархий, превратив вертикальную структуру в горизонтальную, нельзя. Необходима хорошо развитая коммуникационная инфраструктура, поскольку горизонтальные организации могут легко разрушиться при ее отсутствии. Это легко объяснимо — структуры с большим количеством сотрудников, на каждого из которых приходится солидный объем работ, не способны работать без системы, обеспечивающей оптимальную и эффективную координацию всех действий и процессов в компании. Единственной устойчивой организацией, которая сможет пережить любые происходящие изменения, является та, которая сама постоянно меняется. Но обычно причиной большинства удачных изменений служит субъективный кризис: дальновидность управляющего, почувствовавшего новую тенденцию на рынке; уменьшение прибыли. При этом вокруг достаточно примеров организаций, которые осознали свое критическое положение только тогда, когда изменения стали уже невозможны. Планирование изменений во многом напоминает защиту от пенальти в футболе: если ждать до тех пор, пока не определишь направление удара, то наверняка опоздаешь. Однако всегда ли даже самый дальновидный управляющий может вовремя принять правильное решение и в нужный момент изменить направление? Это возможно, но только при постоянной и объективной обратной связи, доступной тем, кто принимает решения. Только такой способ управления позволит горизонтальной организационной структуре работать слаженно и эффективно. В мире такая технология уже существует.

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

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

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

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

Что такое workflow? Значение термина workflow

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

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

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

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

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

Но без автоматизированной системы workflow это возможно только когда два человека свободны в одно и тоже время. Конечно, никакая технология не может повернуть время вспять, однако можно устранить главное препятствие синхронной коммуникации: одновременность человеческого общения. Workflow видоизменяет процесс таким образом, что общение может происходить в любое время. Возможности технологии workflow значительно расширились с развитием Интернета. Интернет предоставляет возможность не только значительно увеличить объем получаемой информации, но и руководить процессом как внутри организации, так и вне ее, напрямую активно взаимодействуя с клиентами, поставщиками и партнерами. В России всплеск интереса к технологии workflow произошел в начале 90-х годов. Сегодня наблюдается "второе пришествие" workflow на российский рынок. Актуальной стала, в первую очередь, практическая значимость и возможность адаптации workflow в наших условиях. Оказалось, что эта технология необходима нашим предприятиям. Для российских компаний внедрение подобных систем означает упорядочивание деятельности, приведение ее к четким процедурам и значительное повышение эффективности работы.

Каждый серьезный материал на тему “workflow” начинается с интерпретации самого этого термина. Его, как правило, оставляют в тексте в оригинальном английском написании, поскольку устоявшегося аналога в русском языке так и не появилось. “Workflow” обычно переводится как “поток работ” или “рабочий поток”, что почти одно и то же, если отбросить нюансы. В различных источниках можно обнаружить перевод этого слова и как “деловой процесс” (или “бизнес-процесс”). Однако это не синонимы, хотя оба понятия неразрывны.

В общем, в России существует значительная путаница понятий вокруг workflow.По сути своей workflow — это технология эффективного управления и мониторинга процессов деятельности. (С точки зрения образования новых форм в английском языке было бы правильнее, если бы эта технология называлась “workflowware”, но обилие неочевидных буквенных сочетаний и длина слова привели к более лаконичной форме.)

Согласно глоссарию WfMC (Workflow Management Coalition, http://www.wfmc.org/), международной организации, занимающейся введением стандартов в системах workflow, бизнес-процесс — это одна или несколько связанных между собой процедур или операций (функций), которые совместно реализуют некую бизнес-задачу или политическую цель предприятия, как правило, в рамках организационной структуры, описывающей функциональные роли и отношения (см. рис.1).


⇐ Предыдущая77787980818283848586Следующая ⇒


Дата публикования: 2015-10-09; Прочитано: 191 | Нарушение авторского права страницы



studopedia.org — Студопедия.Орг — 2014-2018 год.(0.002 с)…

Правила Варфейс

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

В warface есть некоторые правила, которые все игроки обязаны соблюдать.

За нарушение или неоднократное нарушение установленных норм поведения производится блокировка аккаунта. Красота — важнейший элемент в вашем доме. Чтобы сделать жилье более уютным, закажите литьевые элементы декора на этом сайте tantiema.com.ua 

 

Правила Варфейс — Все пункты

 

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

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

Пункт 2. Нужно уважать других геймеров и не мешать им своими действиями спокойно играть.

Пункт 3. Запрещены покупка/продажа/обмен/передача/дарение игрового аккаунта.

Пункт 4. Нельзя продавать друг другу внутриигровую валюту/предметы.

Пункт 5. Создание ботов

Пункт 6. Использование игровых багов.

Мощная и простая система автоматизации процессов

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

Пункт 7. Игрок обязан вовремя оплачивать взятые кредиты и т.п.

Пункт 8. Все платежи должны осуществляться легальными средствами.

Пункт 9. Распространение слухов/клеветы обо всем, связанным с игрой Варфейс.

Пункт 10. Спам/флуд

Пункт 11. Распространение политической/религиозной информации в игре

Пункт 12. Несанкционированная реклама (в т.ч. ссылки на сайты)

Пункт 13. Использование ненормативной лексики в названии персонажей/кланов/других игровых объектов.

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

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

Пункт 16. Намеренное совершение действий, затрудняющих доступ к игре другим игрокам или создание помех, не предусмотренных игровым процессом.

 

Пункт 17. Публикация ссылок на вредоносные программы (вирусы, трояны и т.п.)

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

Пункт 19. Взлом чужих аккаунтов или распространение информации о взломе.

Пункт 20. ЧИТЕРСТВО (все понимают что это такое, ага)

Пункт 21. Запрещено фальсифицировать/удалять/отключать информацию об авторском праве.

Пункт 22. Игрок должен соблюдать законы РФ (или своей страны для иностранцев)

Пункт 23. Запрещено приводить агрумент «соответствие роли» в защиту неправомерных действий.

Пункт 24. Сообщение заведомо ложной информации при обращении в Единый Центр Поддержки.

Старайтесь не нарушать правила. Это просто. Для идеальной игры нужно очень немного. Приятной игры в Warface.

 

На последок предлагаем вам посмотреть видео, в котором игрок нарушает правила игры и его за это пока не наказали (читер).

Статьи | 3.07.2013 | 71502 просм.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *