В этот раз я решил набросить на историю, когда кто-то из руководителей решает, что он лучше всех разбирается в предмете и принимается внедрять налево и направо различные правила, регламенты и стандарты. Очень часто это встречается у молодых вождей, которые сменили работу, увидели, что тут всё иначе, а значит не работает скорее всего. Или увидели, что не работает. А значит нужно срочно починить (я немного писал про это в эпизодах 14, 15 и 16). И часто решение находится простое — П — процессы, Р — регламенты, С — стандарты. Если их нет, то точно всё не так выполняется. Как оно получается на самом деле под катом TL;DR;

В ИТ почти всегда всё, что связано с стандартами и регламентами создаёт у руководителей высшего звена ложное чувство безопасности (я не говорю про стандарты вроде PCI DSS или DO-178B, без них нельзя, я скорее про что-то более местечковое). Когда у вас есть «стандартный» подход к проектам или чему-либо еще в вашей организации, менеджеры разных уровней ощущают себя в безопасности. Это ложное ощущение, но оно почти всегда есть. А чего переживать? У нас есть регламенты, процессы, стандарты, отдел QA (который обычно вовсе не QA) и пр. Очень часто при наличии стандартов почему-то считается, что работа будет идти гладко, без ошибок и потерь. Как часто это происходит? Да почти никогда! А вот когда ничего такого нет, и дела тоже идут так себе — почему-то первое, что приходит в голову — давайте что-нибудь стандартизируем, иначе не полетит. И это, на секундочку, вместо того, чтобы разобраться в истинных причинах проблем.

На деле вы можете стандартизировать работу на линии консервного завода и сделать ее более безопасной и эффективной. Но получится ли такой же фокус с интеллектуальной работой? И это в эпоху гибких методологий. Когда вы стандартизируете интеллектуальную работу, вы рискуете сделать её скучной, негибкой, менее эффективной и не ориентированной на реальную цель вашего проекта. А в ряде случаев наличие «кривых» стандартов и регламентов могут просто поставить всё в позу коровы на льду — и стоять не могу, и идти не могу. Вдруг вы никогда не видели корову на льду — вот.

Интеллектуальная работа уникальна и включает в себя непрерывное совершенствование всего, что её касается и обучение коллег. Иначе местность заболачивается очень быстро. А ещё она снаружи очень сложно оценить сложность задач и витиеватость зависимостей. Вот почему каждый проект волен (а чаще должен) разрабатывать свой собственный подход, независимо от того, начинается ли он как водопад, или как итеративный, или инкрементальный, или гибкий, или как адская смесь всех упомянутых. Понятно, что есть какая-то генеральная линия, по которой движется всё, но по факту не существует единого правильного способа выполнять все проекты. Даже очень похожие внешне и внутренне проекты могут выполняться со своим изюмом. Потому что внутри ЛЮДИ, очень много людей, и часть из них часто не очень разбирается в том, что нужно делать, до того, как им не рассказали. Каждая проектная группа должна решить, как и что делать для своего собственного проекта. Каждая инженерная группа должна решить, как и что делать для своего собственного проекта. С соблюдением всё той же генеральной линии, которая в начале начал была рождена командой!

Здесь пытливый читатель может заподозрить меня в анархизме, нигилизме и лудизме, нелюбви к менеджерам разных мастей — нет! Ни в коем случае. Я сам последние 15 лет менеджер в разных вариантах. Читайте дальше.

Неправильно навязывать стандарты чужой работе

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

Когда менеджеры навязывают стандарты, они неявно говорят: «Я не доверяю вам выполнять свою работу. Я расскажу как вам нужно работать.»

Когда менеджеры навязывают процессы, они неявно говорят: «Вообще не понятно, что у вас происходит. Мне лень в этом разбираться, поэтому будем делать вот так, потому что так у меня будет ощущение, что я понимаю, что и как вы делаете».

Многие захотели бы делать свою работу хорошо в таких условиях? Спорно. И практика это подтверждает. Всё, что рождается за пределами системы исполнения и без её участия — не работает, будь то стандарт или метрика.

Я не против иметь правила игры. Я могу жить с ограничениями. Более того, на определённом уровне стандарты нужны, но по опыту они хорошо работают там, где речь не идёт про творчество. Кодстайл? — механика. Правила обработки пул-реквестов? — механика. Релизный цикл? — механика. Интерфейс АПИ? — вроде механика, но уже с примесью интеллекта, т.е. чуть сложнее, поэтому с апи всегда куча проблем. А вот вопросы реализации функционала, вопросы преобразования бизнес-требований в функциональные спецификации, вопросы коммуникаций, распределения задач, зон ответственности и т.д. чаще всего имеют очень характерные конкретной команде и проекту черты.

А ведь речь может идти не только про процессы и стандарты. Такой же эффект достигается, когда вам просто говорят КАК делать свою работу. Бывали случаи, когда менеджеры и, чуть реже, руководители говорили мне, как именно выполнять мою работу, вместо того, чтобы потратить время на обсуждение цели и желаемых результатов. Чаще всего я не очень хорошо реагировал. Я всегда думал и продолжаю думать, как сделать то, что я должен сделать лучше. Но иногда менеджмент не ценит такие мысли. Скорее всего это связано с тем, что всё, что люди не понимают, вызывает у них первобытный страх и желание убрать этот раздражитель. И про это нужно помнить и помогать разбираться заинтересованным коллегам безотносительно их должности и положения в системе.

Неуместные стандарты мешают людям думать

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

Хороший пример нелепой стандартизации интеллектуальной работы — попытки сделать универсальный флоу задачи в Jira. Я неоднократно видел заходы на эту операцию именно со стороны менеджмента, вероятно, потому что им неудобно собирать адекватную и понятную доску со всеми статусами, да ещё и по трём командам одновременно, при том, что проекты и задачи у них принципиально разные.

Зачем мы нанимаем людей в программную инженерию? — Думать и решать проблемы. Разве мы не хотим, чтобы люди думали? Нет. Мы хотим, чтобы люди думали. Мы хотим, чтобы люди много думали. Мы хотим, чтобы люди решали проблемы, будь то процесс или продукт. Но при этом хотим, чтобы всё было прозрачно, прогнозируемо и зачем-то одинаково. И если к первым двум пунктам вопросов нет, то к последнему их куча, за редким исключением.

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

Что делать, если людям нужна помощь?

И правда бывает так, что сотрудникам нужна помощь с нормализацией и стандартизацией, особенно для «молодых» команд, которые ещё не сработались. Но, по опыту, лучшее, что можно предложить — каждой команде адресную помощь. И если команды являются частью большого продукта, где одна большая цель, общая для нескольких проектов, лучше убедиться, что в рамках большого продукта нет такой же проблемы. А может быть её уже решили? Пусть команды соберутся и решат проблему на уровне большого продукта. Если им понадобится помощь, они ее попросят. Главное, что здесь стоит делать — максимально отзывчиво реагировать на такие просьбы.

Вместо итогов

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

Пусть люди решают проблемы. У них это хорошо получается. А если нет, позвольте им попрактиковаться. Ошибаться полезно, если делать это без боязни быть наказанным.

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

Больше эпизодов про значение личности тут

Обновления блога доступны в Телеграмм-канале

[sgmb id=»1″]