Суррогаты

в 18:10, , рубрики: Анализ и проектирование систем, бизнес-модели, Внедрение, Карьера в IT-индустрии, смысл жизни, Управление продуктом, управление проектами

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

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

При этом, как ни странно, бизнес любит:
1. повышение прибыльности бизнеса за счет автоматизации;
2. увеличение количества лидов и рост оборота за счет правильного продвижения;
3. повышение качества процессов производства и бизнес-процессов;
4. полезный бухгалтерский учет, дающий простую и понятную картину бизнеса в цифрах по принципам двойной записи;
5. полезный управленческий учет, дающий своевременные цифры и прогнозы состояния компании;
6. эффективные проекты повышения эффективности, запущенные и выполненные внутри компании, с небольшим бюджетом и сохраненными в компании компетенциями;
7. повышение эффективности проектной или потоковой работы в 2-4 раза;
8. кратное увеличение оборотов и прибыли, снижение всех видов запасов, избавление от избыточных мощностей всех видов;
9. точную систему управления, своевременно реагирующую на отклонения и помогающую принимать правильные решения всем участникам процессов;
10. многогранную, понятную, правильно сходящуюся в 1-3 цифры систему оценки всех областей бизнеса, дающую оценку состояния дел за несколько минут без длительных совещаний и докладов;
11. четкую систему измерения и оценки человеческого труда, которая еще и выполняет функцию управления, позволяя разогнать половину ненужных менеджеров, которые любят «руками водить» (=«руководить»).

Чувствуете разницу? Или еще нет? Я специально сделал список один к одному, чтобы можно было сопоставить.

Чтобы еще сильнее вас запутать, добавлю п.12, общий для всех: бизнес очень любит читать книги разных гуру про все перечисленные темы, того же Гейтса, Деминга, Оно, Голдратта, Сазерленда и т.д.

Теперь, уверен, вы все поняли.

В книгах – оригинал, эталон. Как оно должно быть. Ради чего оно было придумано. Цель. Что должна давать автоматизация бизнесу. Как ускоряется работа над проектом в 4 раза. Как потери от брака сделать вероятностью, а не реальностью. Как управлять бизнесом, тратя на это 20 минут раз в месяц и читая один лист А4 с тремя цифрами. Как увеличить оборот в разы, просто покупая только то, что нужно. Кому ж такое не понравится? И люди авторитетные пишут, и на практике все проверено, и съездить посмотреть можно. Оригинал. Как Мона Лиза в Лувре, у которой всегда толпы китайцев и японцев.

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

И тут вступают в действие друзья из первого списка. Не знаю лучшего фразеологизма, который опишет первый список, чем «хотели как лучше, а получилось как всегда». Есть еще чуть менее подходящий – «не догоним, так хотя бы согреемся».

Есть, правда, и антипаттерн, приведу ключевую цитату: «Наша работа заключается в том, чтобы найти наиболее удобный, простой и красивый способ решения поставленной задачи, не потеряв по дороге смысл». Не буду судить, насколько они следуют своему лозунгу, но звучит красиво.

Все, хватит ходить вокруг да около, эта статья – про суррогаты и их производителей.

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

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

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

Я когда-то был 1Сником. Начал работать в 2005 году, сразу с v8 и УПП, поэтому застал большой хайп автоматизации производственных предприятий, который был в 2005-2009 годах.

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

И всегда – всегда – заказчик получал одно и то же. Заказчик всегда получал автоматизацию бух.учета, регл. расчет зарплаты, зачатки CRM, простецкий управленческий учет, инструкцию по работе с «Помощником планирования», кучу печатных форм на все случаи жизни, кучу кода и обновление релизов часов по 100 каждый (пока УПП не прекратили развивать), необходимость нанять программиста 1С (а лучше двух) и раздутый штат бухгалтеров, экономистов и прочих операторов, которые вместе с программистом 1С становятся придатками системы.

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

Еще одна богатая суррогатами отрасль – это менеджмент качества. Наверняка слышали про «внедрение системы менеджмента качества в соответствии с международными стандартами ISO 9001». Это почти всегда – суррогат.

Здесь исключения уже бывают. Например, компании нужен сертификат ISO, чтобы участвовать в тендере. Тогда все честно – сертификат можно просто купить (это незаконно, конечно, но можно).

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

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

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

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

Есть масса менее распространенных производителей суррогата. Сюда можно отнести большую часть бизнес-консультантов со всеми их ТОСами, Scrum’ами, Lean’ами и т.д.

Про сайтоделателей и упоминать не стоит. Достаточно вспомнить, зачем их приглашают – продажи увеличить.

Теперь – про то, как и почему суррогаты все-таки появляются. Должны же они каким-то законам подчиняться.

Производство суррогатов, как тренд, зиждется на трех китах: формализм, постепенность и круговая порука.

Главный, наверное, формализм, вы все о нем знаете. Это первый этап производства суррогата. Начинается с фразы «давайте теперь зафиксируем на бумаге». Так появляются разного рода требования, договоры, проекты, этапы, графики, сроки. Обычно в проектной документации не забывают упомянуть и цель проекта – те фантазии, которые заказчик на первой встрече говорил. Но как мы знаем из жизни, никто раздел «Цели» потом уже не перечитывает.

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

Видите, что происходит? Банально – перенос фокуса внимания. Как часто пишут в оппозиционных СМИ, перевод внимания с реальных проблем на выдуманные. Создаем проблему, с которой надо много возиться, и человек увлеченно возится.

Например, с контролем сроков выполнения работ. Это ж излюбленное дело всех менеджеров – сроки контролировать. А когда речь о многомиллионном проекте, так и щеки надувать сам Бог велел – я занят важным делом, сроки контролирую.

На этом этапе цель проекта вообще пропадает из поля зрения. О ней уже никто не вспоминает. И чем дальше, тем меньше будут вспоминать.

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

А что на самом деле? Вот в среде 1С: Франчайзи, например. Приходя с проектом внедрения на предприятие, мы ведь заранее знаем, что там будет внедряться. Послушать цели проекта – это скорее формальность. Мы просто отметим галочками те подсистемы, которые на данном предприятии в приоритете. Ну и те, на которые можно заложить побольше часов из-за пристального внимания руководства предприятия, или (бывает) нездоровой любви к какому-то конкретному участку.

Не нужны нам твои цели, дружище. Нам твой бюджет нужен, и давай побыстрее зафиксируем все это на бумаге.

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

Еще в проектной документации, кроме целей проекта, пишутся критерии успешности. Вроде правильная штука – формула, по которой оценивается, был проект успешным или нет.

Когда речь о внутреннем проекте, выполняемом сотрудниками самой компании, то смысл в критериях есть. От них зависит карьера руководителя проекта и ключевых сотрудников. Сделал проект по сокращению бухгалтерии, если по факту бухгалтерия сократилась – ура, ты Великий Сократитель Бухгалтерии. Тебе с высокой вероятностью доверят сокращение экономистов. Или даже предложат, может и настаивать будут.

А если это внешний проект, с франчем? Кому нужны эти критерии успешности, если все этапы позади, акты подписаны, деньги заплачены? Ну, собственнику наверное нужны, чтобы в очередной раз убедиться, что не за что любить 1Сников. А если в первый раз с таким столкнулся, то поплакать и погрузиться в наш реальный мир.

Формализм сопровождает суррогаты везде. Чтобы это увидеть, надо лишь оглянуться вокруг.
Посмотрите на гос.управление. На законотворческую деятельность. На ваш город. На вашу управляющую компанию. Постарайтесь увидеть суррогат. Сейчас, кстати, самое время – скоро выборы. Кто сейчас вспомнит, какие перед этими ребятами стояли цели? Не такие, типа «развитие вверенной территории», а конкретные, измеримые, понятные. Они и сами не помнят. А что они будут вам впаривать в качестве результата своей работы? Да все что угодно – то, что вопреки формализму успели сделать, даже если это не они делали.

Построили детский сад – вот наш результат, скажут они. А цель какая была? Обеспечить всех детей от 2 лет детскими садами. Сколько для этого надо было дет.садов построить? 15, допустим. А они один построили. Суррогат? Ясен пень. Его еще и построил не город, а застройщик микрорайона, потому что обязан был.

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

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

Все это заказчик узнает по ходу проекта, от первого до последнего пункта, плюс еще с десяток. Но узнает постепенно, иначе произвести суррогат не получится – просто не подпустят.

Постепенность крайне важна. При правильном использовании вектор проекта или продукта можно постепенно развернуть и на 180 градусов, и в змейку скрутить. Чтобы всей душой прочувствовать, насколько сильна постепенность, настоятельно рекомендую выбрать время и посмотреть фильм «Догвилль» Ларса фон Триера. Когда я был ИТ-директором, этот фильм был обязательным к просмотру для всех подчиненных программистов. Там, правда, цель была немного другая, более мелкая.

Фильм должен был показать программистам, как кит «постепенность» превратит их самих в суррогатов. Каждый программист ведь в душе считает себя архитектором, строителем системы, повышателем эффективности бизнеса. Это без иронии – так оно и должно быть.

А что происходит дальше с таким романтиком?

Пользователь: «А помоги мне настроить отчет…»
Программист: «Давайте я лучше вам расскажу, как вообще отчеты настраивать, сможете сами»
Пользователь: «Да сейчас некогда, начальник ждет, ну помоги»
Программист: «Ладно, сейчас»

Пользователь: «Нам бы распределение затрат настроить, месяц не закрывается»
Программист: «Я ж вам показывал, как это делать, обучение проводил, инструкцию написал»
Пользователь: «Ну что-то не получается у нас, помоги, тебе трудно что ли, ты ж программист»
Программист: «Нет, не буду, я вам не мальчик на побегушках, вам за это зарплату платят»
Пользователь: «Нам завтра прибыль сдавать, я директору скажу, что ты не помог, посмотрим потом, кому за что платят!»
Программист: «Ладно, в последний раз помогу»

Пользователь: «Слушай, у нас новый прайс с ценами поставщика, залей в 1С»
Программист: «Сам залей»
Пользователь: «В смысле сам? Ты ж программист»
Программист: «Я программист, а не оператор. Я программы пишу, а не данные вколачиваю»
Пользователь: «Да я не прошу вколачивать, залей, ты же умеешь»
Программист: «И ты умеешь, я тебе обработку написал, там только колонки надо выбрать, где номенклатура, где цена»
Пользователь: «Да не помню я, где она»
Программист: «Ну так ищи, письмо от меня было, в декабре вроде»
Пользователь: «Слушай, мне некогда, через час совещание по тендерам, надо чтобы данные уже в системе были. Заливай, или я скажу, что из-за тебя нам тендер продлевать»
Программист: «Ну ты скотина. Давай свой файл и готовься к совещанию, я все расскажу»

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

Диалоги вы сами можете дополнить, все мы видели такие грустные истории – и на своем, и на чужом примере. Если не врать себе, конечно. Это – постепенность. Есть еще другой синоним в данном контексте – рутина. Которая, как известно, убивает брак, отношения с детьми, мечты и личные цели, и т.д. Все, завязываю, слишком грустная тема.

Остался последний кит – круговая порука. Она бывает явной, бывает «как-то само сложилось». Но без нее индустрия суррогатов не выживет.

Все, что я написал про работу франчей, я написал про все франчи. Это – результат круговой поруки.

Если вы – заказчик, вы не найдете франча, который будет действовать по-другому. Ну т.е. есть те, кто еще хуже действует, но лучше – нет. У всех одинаково. Конкуренция – только по второстепенным критериям, типа количества специалистов и неподтвержденных компетенций.

Франчи, конечно, нашли себе отмазку – вендора. Внедрения программ 1С получаются такими, потому что программы 1С такие. Почитайте холивары по этой теме на партнерской конференции, если доступ есть. «Мы для вас деньги зарабатываем, а вы такую плохую программу сделали, и нас не слушаете!». Я не защищаю 1С, она в этом не нуждается, но, все-таки, если голову из неправильного места вытащить, то придется признать, что проблема проекта – это проблема проекта, т.е. «временного предприятия, направленного на создание уникального продукта, услуги или результата (см. PMBOK)», а не внедряемого программного продукта.

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

Не правда ли, напоминает пресловутое гос.управление? Там круговая порука – это требование к сотрудникам. Читали когда-нибудь требования к гос.чиновникам? Я читал несколько лет назад. Черным по белому написано – запрещено говорить кому-нибудь что-нибудь плохое о гос.управлении, государстве и других чиновниках. Вроде как сор из избы не выносить.

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

Важно помнить о китах – формализм, постепенность, круговая порука.

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

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

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

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

Если вы – руководитель, и ваши люди превратились в суррогаты, производящие суррогат – помните, это ваша вина. Это люди, а не станки и не биоматериал. Вы отвечаете и за их результаты, и за их развитие. Иначе вы не руководитель, а говна кусок диспетчер такси.

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

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

Ну и самое лучшее – разорвите круговую поруку. В программировании и автоматизации даже один человек способен сделать революцию. Пока.

Автор: nmivan

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js