Процесите на работата на iraира се најдобрите практики и типични грешки

За

содржина

  • Дома
  • Вита
  • ингеренциите
  • Консултантски услуги
  • Внатрешна обука
  • Отворени обуки
  • Контакт
  • отпечаток

Работни текови на iraира: Најдобри практики и типични грешки

Кога одам во компанија, секогаш имам список со најдобри практики и типични почетнички грешки за iraира со мене. Оваа листа е многу ценета од моите клиенти, бидејќи грешките често може да се избегнат и секоја грешка да биде критички оценета, особено во почетната фаза на новиот систем. Во следната серија написи, ќе споделам дел од оваа листа со заедницата iraира и очекувам нови предлози и коментари.

процесите

Преинженеринг

Работните процеси на iraира обично се моделираат според процесите на реална работа во компанијата. Овој пристап е точен досега - но треба да се направи разумна рамнотежа помеѓу мапирањето на реалниот работен проток и крајната леснотија на корисникот во iraира. Овој чекор е еден од најсложените и бара извесно искуство со можностите и ограничувањата на iraира. Според мое искуство, златното правило за работни процеси во iraира е:

Колку што е потребно, што е можно помалку!

(Или, исто така, принципот „КИШКИ“: Држете го кратко и едноставно). Тоа значи: колку што е потребно чекори на работниот тек, но што е можно помалку. Кои од реалните чекори на работа се потребни како чекор на работа во iraира, не може да се одговори во принцип, бидејќи секогаш треба да се земат предвид специфичните околности на компанијата и вработените. Сепак, постојат неколку прашања што можат да се искористат за да се провери дали е неопходен чекор:

  • Има промена на одговорноста?
  • Само одредени луѓе или групи на корисници нека го спроведат овој чекор?
  • Известувањата треба да се испратат?
  • Дали треба да можам да филтрирам по овој чекор, т.е. да имам можност да видам преглед на сите процеси во поврзаниот статус?

Колку повеќе од овие прашања ќе бидат одговорени со „да“, толку посигурно овој чекор исто така треба да биде мапиран во iraира. Честопати премногу чекори се вградени во работниот тек во фазата на зачнување, што резултира во преинженеринг споменат на почетокот. Таквиот работен тек е технички точен, но неговата сложеност предизвикува неразбирање кај корисниците - резултатот е неправилно работење и отфрлање на новата алатка. Негативен пример:

Измислената компанија RequirementsUnlimited би сакала да спроведе управување со внатрешните барања со iraира. Затоа, се создава работен тек што го рефлектира техничкиот процес кога е забележано барање. Првите 4 чекори за типот на активност „Барање“ се: Отворено, во координација, одобрено, закажано.

Досега звучи прилично добро. Меѓутоа: за да прифатите ново барање, потребни се 4 чекори на работниот тек, преку кои корисникот треба да „кликне“ во случај на сомнеж. Значи, тука треба да проверите дали сите чекори се навистина потребни. Со RequirementsUnlimited, на пример, единствената разлика помеѓу статусот „Одобрено“ и „Закажано“ е што процесот во оваа статусна транзиција е доделен на одредено издание (во Jира, верзија на решение). На прашањето зошто е потребен посебен статус за ова, раководителот на проектот одговара: „Сакам да можам да филтрирам кои процеси се препознаваат, но сè уште не се планирани!“. Со оваа информација, сега со чиста совест може да препорачате да го избришете чекорот „Закажан“: Можете исто така да користите филтер за прикажување на сите процеси што имаат статус „Одобрен“ и не се доделени на ниту една верзија на решението. Ако опцијата за филтер беше единствениот услов за чекорот "Закажан", ова може да се избрише и да се прилагодат постојните филтри.

Во примерот, на почетокот може да звучи тривијално, без разлика дали работниот тек има еден повеќе или помалку чекор - во поголеми и посложени работни текови, сепак, секој дополнителен чекор создава ново ниво на сложеност и зависности. Задржувањето на ова ниско ниво е целта на чистиот и лесен за работниот процес.

Лошо именување при статусни транзиции

Популарен извор на слаба употребливост на работните текови е именувањето на статусните транзиции. Кога креирате функционален работен тек, некој е склон да ги именува транзициите на статусот во согласност со она што се случило во последниот статус, наместо она што ќе се случи во следниот статус. Треба да знаете дека имињата на статусните транзиции се прикажани на корисникот како достапни чекори на работниот тек:

Во повеќето случаи, корисниците на iraира знаат што штотуку се случило со процесот и наместо тоа, сакаат да видат во приказот на достапните чекори до кои ќе дојде последователниот статус на секој чекор. Негативен пример:

Транзиција на статусот „Гласањето заврши“ неизбежно го води корисникот кон прашањата „Што значи тоа?“, „Што ќе се случи ако сега кликнам на него?“. Резултатот е уште еднаш неизвесност и неправилна работа. Во овој пример, статусната транзиција треба подобро да биде како што следува:

Со ознаката „Процесен процес“, корисникот може веднаш да го види последователниот статус во кој ќе го доведе неговото дејствие. Правилото за именување на статусните транзиции е: Името на статусната транзиција мора да го покаже последователниот статус на процесот.

Ова беа само два од бројните примери што треба да се земат предвид при дизајнирање и поставување на работни текови во iraира (меѓу другото: употреба на решени и затворени статуси, глобални статусни транзиции, доделување услови за работни текови и многу повеќе). Во овој момент, се разбира, моето последно прашање: Кои грешки или проблеми наидовте при креирање на работни текови? Се радувам на вашиот коментар!

Слични написи

28 ноември 2012 година од Себастијан Хоне
Категории: iraира | Тагови: Најдобри практики, Jира, Тек на работа | 7 коментари