Защита от впихивыния невпихуемого
(Из ленты 255 ступеней)
Попытка решить слишком много задач приводит к снижению производительности, нервотрепке и отрицательному естественному отбору. Снижение производительности на 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. Разработчики взаимозаменяемы.
Источник: Защита от впихивыния невпихуемого