Бизнес не любит:

1. 1С-Франчайзи, программистов 1С вообще, и почти все, что те делают;
2. веб-программистов и компании, создающие и продвигающие сайты, и все продукты их работы;
3. системы менеджмента качества и людей, которые занимаются их внедрением;
4. бухгалтеров и бух.учет;
5. экономистов со всеми их гигантскими экселевскими портянками;
6. внутренние проекты развития, на которые без слез уже смотреть невозможно;
7. Scrum и все эти доски, на которых неделями висят одни и те же стикеры;
8. ТОС, после внедрения которого дефицитов и неликвидов становится еще больше;
9. Контроллинг, который дает цифры позже, чем бух.учет;
10. KPI, адекватность которого приходится доказывать самому себе каждый раз, когда приносят эти цифры;
11. Системы мотивации, которые, как ни крути, «оклад+премия», хоть и названы модными словами, типа «грейд».

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

При этом, как ни странно, бизнес любит:

1. повышение прибыльности бизнеса за счет автоматизации;
2. увеличение количества лидов и рост оборота за счет правильного продвижения;
3. повышение качества процессов производства и бизнес-процессов;

Эта публикация — про то, как программист помогает создавать суррогаты.

Суррогат – это когда сделали не то, что нужно бизнесу. Или не так, как нужно бизнесу.

Суррогаты – это самое страшное зло, происходящее сейчас с российским бизнесом и государственным управлением. Суррогаты – это лучший в мире киллер эффективности. Что особенно приятно, мы, программисты, на этот раз не в стороне – мы на самой оси зла.

С чего все начинается

Представьте исходную ситуацию. К программисту, работающему в «обычной» компании, подходит человек – пользователь системы, он же – руководитель некоего подразделения. Просит, или предлагает, или просто нейтрально говорит – надо сделать в программе/системе/на сайте такую-то штуку.

Программист, допустим, толковый – он понимает, что предлагаемая доработка – суррогат.

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

Статья написана как для руководителей, так и для программистов, т.к. описанные методы применимы и для подчиненных, и для себя.

Сначала кратко методику (не все с ней работали), потом – главное, зачем ее применять.

Методика измерения

Сама методика известна давно, никакого секрета собой не представляет – это покер планирования из Scrum. Чтобы ее применять, не нужно применять весь Scrum.

За годы работы ИТ-директором, среди руководителей разного уровня, сделал одно наблюдение — забавную разницу в подходах к постановке задач и контролю их выполнения.

Есть нормальные, адекватные постановка и контроль, которые приводят к решению задачи, двигают вперед и улучшают состояние компании.

А есть странные, забавные, иногда неприятные способы, которые приводят к повышению ЧСВ руководителя, разрушению команды, ухудшению состояния компании, интригам и междоусобицам.

В чем эта разница? Попробуем разобраться.

Кошка сдохла, хвост облез – кто слово скажет, тот ее и съест. Все знают эту детскую считалочку.

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