Старт проекта

Работа в команде: действуем четко по инструкции.

В чем проблема?

Есть инструкция, есть описанный процесс, но все равно идет постоянное отступление от процесса. Приходится практически каждый шаг вручную контролировать. 

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

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

Мне не нравится заниматься контролем людей, и не нравится, когда мне кто-то садится на хвост. 

Как же быть?

Я пришел опытным путем к следующему. Представьте лес зимой с глубоким снегом. И в этом лесу есть одна лыжня. Куда вы поедете? Правильно, по лыжне. Больше просто некуда. 

Необходимо создавать систему так, чтобы вообще не было вариантов движения. Все нештатное решать через админа. 

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

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

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

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

Конечно, далеко не каждая система дает возможность внедрять тонко бизнес-правила. Но в нашем случае это возможно. 

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

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

Главный посыл – создавайте лыжню. Никакие уговоры, инструкции не помогают так, как лыжня в зимнем лесу.

editor

Recent Posts

Форма теста внешних действий #falconstart

Вызов внешних действий - это возможность действия, выходящего за рамки возможности работы с БД через…

2 недели ago

Концепция внешних действий – telegram, email, уведомления на сайте

Вызов внешних действий - это возможность действия, выходящего за рамки возможности работы с БД через…

2 недели ago

Работа с JSON в SQL #falconstart

После выполнения действий в SQL на клиенте иногда возникает необходимость что-то обновить или сделать. Для…

3 недели ago

Форма с отправкой запроса API. Тестирование исходящих запросов #falconstart

Вы можете обратиться к внешним API через использование Внешних действий (код apirequest, использование описано в…

3 недели ago

Таблица Trace для отслеживания событий на сайте

В системной таблице as_trace хранятся данные по работе приложения. Поле code определяет тип события: DBLREQ…

3 недели ago

Работа с ошибками в системе. Генерация отчета по ошибкам #falconstart

Рассмотрим механизм анализа ошибок, как это всё работает, и как его использовать. Когда происходит ошибка…

4 недели ago