– Добрый день, Станислав Сергеевич! Проходите, пожалуйста!

– Здравствуй, Катенька! Прохожу, прохожу…

– Чай, кофе?

– Ну… Не знаю я. Ничего, наверное.

– Хорошо, как скажете. Я немного волнуюсь, если честно – в первый раз через эту процедуру проходит программист…

– Ну, не клизму же ставить будете, Катюш. Не бойтесь, я вас не съем.

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

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

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

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

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

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

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

Некоторые из них действуют смело и решительно — пытаются доказать всему миру, что 1С — это не программа для бухгалтерии, это самая крутая платформа для автоматизации бизнеса, уверенно захватывающая рынки, осваивающая новые технологии, создающая и развивающая свои собственные. Такие люди, безусловно, вызывают самые сильные ответные чувства. Они — как сильные, гордые и уверенные в себе отрицательные герои фильмов. Ну, знаете, такие, которые затмевают положительных.

Но большинство 1Сников, увы, не такие. Скромные, тихие, считающие свою «одинэсность» — постыдным недостатком, психическим или физическим заболеванием. Читая Хабр, они вынуждены скрывать свои «желтые трусы», чтобы не быть с позором изгнанными, оплеванными и поруганными.

Они читают о разработке игр, веб-приложений, машинном обучении, работе за рубежом, Google и Apple, и плачут. А потом отторгают, злятся, бросают читать, возвращаются в бухгалтерию… Но возвращаются снова и читают.

Публикация — для них.

Пролог

— Ты, главное, не ссы! Держись меня, делай как я, и все будет чики-пуки.

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

— Коль, давай посерьезнее. — Жанна строго посмотрела на круглую самодовольную рожу. Потом перевела взгляд на новенького. — Сергей, не слушай этого старого коня. Борозды он, конечно, не испортит, но и целины не поднимет.

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

— Мы на тебя возлагаем большие надежды, Сережа. Николай у нас под завязку загружен текучкой — ее очень много. Мы понимаем, что действуем неэффективно, где-то что-то упускаем, используем устаревшие технологии и подходы… Но у нас реально нет времени остановиться, подумать, посмотреть, поучиться. Как писал Кови — наточить пилу.

Сергей понимающе покивал головой. Он не знал, кто такой Кови, но метафору понял.

— Ты — молодой, целеустремленный, не обремененный обязательствами и связями, амбициозный, и очень умный программист. У тебя за плечами очная Бауманка. Мы ждем от тебя новой струи свежего вохдуха, скачка в развитии наших систем, прорыва облачных технологий. Так, и только так!

— Спасибо, Жанна Ивановна. Я буду стараться.

— Никакого отчества, просто Жанна! Велкам в нашу команду, Сережа!

У программистов, как и у всех людей, есть фобии. Кто-то боится маньяков, кто-то — утки, которая следит за человеком, кто-то впадает в панику при нарушении привычного распорядка дня, кого-то начинает штырить от внезапно пропавшей связи в смартфоне.

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

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

В этой статье — истории реальных программистов и их профессиональных фобий, которые мешали им жить и работать в свое удовольствие. Люди реальные, имена вымышленные.

— Бизнес, остановитесь. Пройдемте.

— Куда, зачем?

— Там узнаете. Поверьте, это в ваших же интересах.

— Надеюсь, ненадолго? У меня куча дел, надо деньги зарабатывать. Вас кормить, например.

— От вас зависит, надолго или нет. Идете?

— Да.

Генеральные цели перехода на #Ускорение4X мы обсудили. Теперь нужно сделать еще более важную штуку — учесть цели каждого участника команды. Мы же ускоряемся сами для себя, а не для начальника.

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

Итак, зачем кастомизировать цели? Вроде нормально они звучат — ускориться, научиться работать на форсаже, научиться переводить на форсаж.

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

Такое сплошь и рядом есть во всех компаниях, от всех собственников и менеджеров. Что они там обычно говорят? Давайте увеличим продажи вдвое! Наша цель — войти в список Forbes! Мы хотим через 5 лет выйти на IPO! Наша цель — 5 новых продуктов через год! Ну и т.д. Еще там непонятные миссии добавляются,ценности сейчас модно стало писать, и подобную ересь.

Что с ними не так, вы уже понимаете — там нет вас. Ни про вас, ни для вас, ни про ваше будущее. Вы как были винтиком, шпунтиком или целой шестеренкой, а может быть редуктором/мультипликатором, так и останетесь, пока не выкинут, или сами не уйдете. Никому нет до вас никакого дела. Все корпоративные культуры — искусственная хрень, все похлопывания шефа по плечу — прием из книги по менеджменту (вроде этой), чтобы вы себя лучше почувствовали, квартальная или годовая премия — кусочек колбасы для собаки, чтобы с еще большей радостью делала апорт. Всем на вас насрать. И вам на свои цели давно насрать, потому что вы привыкли к чужим идти. Доходить, постоять, как пел Высоцкий, хмельным на вершине, и ползти на следующую гору, нужную кому-то, кроме вас. Ладно, вы и так это все знаете.

Все, вступления закончились, начинаем изучать практические приемы, из которых состоит #Ускорение4X.

Если вы — тот человек, который берется за внедрение #Ускорения4X в команде, то первый шаг придется сделать вам.

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

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

Напомню, что мы изучаем практику #Ускорение4X.

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

Не знаю, как вы, а я наблюдаю за проектами изменений лет 10. Кроме наших любимых ИТ-проектов (которые ведь тоже — изменения), много приходилось и видеть, и делать самому обычных, организационных изменений.

И в большинстве случаев итог изменений один — не получилось. Изменения не принесли ожидаемого результата. Персонал не сократился, цифры точнее не стали, ускорения разработки не произошло, прибыль не выросла, бизнес-процессы проще и прозрачнее не стали.

Но еще важнее другой, побочный итог — мы убедились, что методика_такая-то — фуфло. Потому что не работает.

Так часто бывает, например, с внедрением принципов agile, или конкретно методики скрам. Так будет и с методикой #Ускорение4X, если действовать с той же ключевой ошибкой — главной ошибкой внедрения изменений в нашей стране.

Ошибка, увы, настолько банальна, что вы мне не поверите. Это не страшно, если не поверите, но если начнете наблюдать за внедрением изменений вокруг вас — в компании, в городе, в стране, то убедитесь, что дело именно в этом.

Продолжаю тему ускорения работы в 4 раза, начатую в публикации про изменяемую среду.

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

На чистом скраме, без всех этих принципов, можно ускориться в 1.5-2 раза, такие примеры есть. Хотя, их достаточно мало. И это парадокс.

Помните публикацию про гибкий суррогат? Я там долго рассуждал о том, что на обложке книги по скраму написано, что она про ускорение работы в 4 раза. Бери и делай, как написано, и получай шикарное ускорение.

Но этого не происходит. Почему?

Я в своей практике ответ нашел, приглашаю и вас ознакомиться. Если хотите 4X.

Итак, мы хотим ускорить разработку в 4 раза. Нет, мы не хотим, мы уже ускорили. Вы хотите.
Серебряной пули, ускоряющей в 4 раза, нет. Есть целая обойма пуль разного калибра, типа, убойной силы и применимости в конкретной ситуации.

Я просто расскажу вам, как это делали мы. Какие нашли решения, фишки, подходы, философию. Нужно это вам или нет – решайте сами. Мы не навязываем. Просто нас задолбали с вопросами по почте и на конференциях, поэтому решили рассказать централизованно, в самом подходящем для этого месте — Хабре. Тут же разработчики опытом обмениваются? Все спрашивающим будем ссылки давать.

На высшую истину и полное раскрытие темы не претендуем, спорить ни с кем не собираемся, мы этот путь прошли. Хотите – тоже проходите.

Если согласны – под кат.

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

Сегодня посмотрим на не так сильно распространенный, но более близкий к нам, программистам и разным ИТшникам, пример.

Конкретно вам НЕ стоит читать дальше, если вы МОЖЕТЕ в течение 5 минут ответить на вопрос: насколько изменилась скорость, или эффективность вашей работы за последние полгода?

Если вы ответили на этот вопрос цифрой, и цифра эта не равна нулю, то публикация не для вас.

Для 1Сников вместо нуля может быть Неопределено, для js'ников — undefined.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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