?

Log in

Предыдущее | Следующее

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

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

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

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

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

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

Пример 2: В мою бытность руководителем отдела документации возникла задача - сменить везде коммерческое название продукта( отдел маркетинга посчитал, что так он будет лучше продаваться). Задача предельно понятная. Стали прикидывать сколько это времени займет - произвели замеры по трудозатратам изменения для одного документа и смасштабировали на весь проект.

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

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

Тем самым для грамотной постановки задачи мы должны:
- зафиксировать исполнителя;
- зафиксировать срок исполнения;
- согласовать с исполнителем объем работы и сроки.

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

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

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

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

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

Comments

( 9 комментариев — Оставить комментарий )
t_a_v_i
20 фев, 2013 14:10 (UTC)
Зафиксировать исполнителя - это хорошая идея =) Чтоб не дергался лишний раз.
Всё правильно... Но вот у ситуация меня интересная - внедрена система управления задачами, но такая, что пользоваться ей удобно только начальнику, она ему отчеты рисует. С точки зрения подчиненных работа с ней - потеря времени, всё равно критически важные поручения записываются "на бумажку". Система тупо с выводом списка текущих задач справляется с трудом.
А уж если задачи организованы в иерархию уровня больше 2-х (что на практике сплошь и рядом) - наступают хаос и глобальная печаль.
vorobiev
20 фев, 2013 14:20 (UTC)
Что у вас за система, если не секрет?

В том то и дело, что система должна быть удобна обеим сторонам. Дальше я буду говорить о контроле и исполнении там приведу примеры, может быть и вам подойдет.
t_a_v_i
20 фев, 2013 15:18 (UTC)
JIRA
Вообще-то она большая и развесистая, её много где используют. Но во-первых, она требует подгонки под конкретные условия использования (Atlassian, собственно, на поддержке и зарабатывает), а во-вторых, она, исходно, багтрекер, в не система управления задачами.
А будучи просто скачанной с сайта и развернутой, являет собой довольно убогое зрелище.
vorobiev
20 фев, 2013 16:15 (UTC)
Да, Jira требует длительной работы по настройке чтобы было удобно. Мы в свое время сильно много к ней дописывали чтобы получить нормальную иерархию задач.

И все-равно было достаточно криво и громоздко. Что любопытно, я когда-то читал что Atlassian для разработки использует не Jira, а физическую скрам-доску :-)
t_a_v_i
21 фев, 2013 14:51 (UTC)
=) я их понимаю.
pkalmykov
20 фев, 2013 16:50 (UTC)
Пример 2, Вывод: для успешного исполнения руководитель и исполнитель должны одинаково понимать объем и трудоемкость задачи.

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

Как часто бывало, что, не договорившись об оглавлении, пишется большой документ без нужных параграфов, или не договорившись о формате таблички собирают какую-то статистику, где в итоге нет нужных деталей, и т.п.
vorobiev
21 фев, 2013 08:02 (UTC)
Да здесь вопрос в терминологии. Под объемом результата подразумевается его запланированный образ. Правда не все в жизни можно просчитать заранее, поэтому образ результата склонен меняться во времени. Отслеживание его изменений в связи с изменениями внешних условий тоже нетривиальная задача.

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

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

cybrat
20 фев, 2013 18:23 (UTC)
где же про автоматизацию бизнес-процессов? )

А про задачи - да, все верно конечно. Даже не знаю, как мы бы работали без системы прожект/таск менеджмента. Уж последние года полтора точно умерли бы.

Неужели для кого-то это новость, и это нужно еще доказывать и обосновывать (что у задач должны быть ответственные, что задачи должны быть зафиксированы)?
vorobiev
21 фев, 2013 07:57 (UTC)
Автоматизация бардака ведет только к дополнительным издержкам. Поэтому сначала немного теории, потом будут практические примеры как это сделать :-)

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

Календарь блога

Апрель 2017
Вс Пн Вт Ср Чт Пт Сб
      1
2345678
9101112131415
16171819202122
23242526272829
30      

Метки

Разработано LiveJournal.com
Designed by Lilia Ahner