Защита от впихивыния невпихуемого

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

Для предотвращения впихивания невпихуемого есть довольно простые правила.

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

Невыдуманная история. В одной из фирм маркетологам запретили чисто устную постановку задачи. Сначала трекер. Только потом можно рассказать устно. Поток гениальности снизился вдвое.

“Если ты не можешь записать идею на родном языке - возможно, тебе рано о ней рассказывать?”

2. Еще до фазы управления идея должна пройти минимальный анализ.

Иногда все очевидно и анализ не записывается. Пример: “Под нового заказчика ООО “Атлант” сделайте новый проект в Jira & пространство в Confluence”. Потому как в регламенте написано про НДА, которое реализуется через разграничение прав доступа к проектам Jira и пространствам Confluence. Но под “поток гениальности” анализ нужно зафиксировать.

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

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

Для случая непрерывной поставки и ограничения находящемся в производстве третье правило трансформируется в регламент со следующими пунктами:

1) Представитель заказчика утверждает порядок очереди работ. Т.е. основное управление осуществляется через “очередь” работ. Чем выше в списке (”ближе к кассе”), тем раньше задачу начнут делать. и вот этот самый порядок в очереди утверждается на встрече представителей заказчика и исполнителя. А если заказчик адекватный, то функции управления очередью можно отдать ему полностью и сэкономить на зарплате менеджера в группе разработки.

2) Задача прожившая в очереди работ более определенного времени (подбирается на основании экспериментальных данных) закрывается автоматически (скриптом). Другой вариант - должна быть не длиннее чем N задач. Например, если в неделю сыплется 10-20, а делается 5-10 задач. То у 50-й задачи нет шансов быть сделанной. За те 6-9 недель, которые нужны, чтобы до нее добраться прилетит еще 100-130 задач. И, если хотя бы половина из них будет поставлена перед 50-й, то…

3) Задачи управляемые по датам (изменение порядка исчисления НДС с 1.04.года) висят в очереди как можно дольше, пропуская вперед все задачи с немедленным экономическим эффектом. Смысл в том, что задачи, управляемые по датам приносят экономический эффект только после наступления этой даты. И для максимизации прибыли фирмы нужно откладывать их на последний момент. Но, естественно оставляя запас по времени под различные риски.

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

* Менеджер не имеет права отдавать указания исполнителям. Исполнителями управляет регламент работ.

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

* Менеджер (не обязательно этот же) может поменять регламент.

——–

Приложение. Дополнения, разъяснения и предупреждения.

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

Для справки. Фирма Хитачи несколько раз пыталась у себя производственную систему Тойота. У них хватало и опытных наставников из Тойота и денег и упорства. Но их производственная среда отличалась от среды Тойота. Итого: потеряв кучу денег они не смогли внедрить производственную систему Тойота и были вынуждены разработать другое прикладное решение под свою среду.

Вот небольшой список вопросов для определения, какое прикладное решение вам подойдет:

* Заказчик. Внутренний / внешний?

* Процесс или проект?

* Какова цена бага пропущенного в продакшен?

* Где находится ограничение системы?

* Сколько рабочих центров задействовано в работе?

* Взаимозаменяемы ли разработчики?

Это не все вопросы, но пока этого достаточно.

Для случая рассмотренного выше, ответы на вопросы будут следующие:

1. Заказчик внутренний. Упрощается взаимодействие. Не нужно «Закрывать контракты».

2. Процесс. Это означает, что задачи слабосвязаны и могут решаться независимо.

3. Цена бага незначительна по сравнению с преимуществом быстрого выпуска.

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

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

6. Разработчики взаимозаменяемы.

Оставьте комментарий

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