IT для неайтишников: Осторожно - JSDD (Бизнес в заложниках у IT)

Продолжаем тему, почему внезапно в IT «всё перестало работать». Мы уже рассмотрели, что может сделать бизнес-заказчик, когда IT хронически срывают сроки. Затем мы поняли, что такое технический долг и почему без его выплаты не получится восстановить работоспособность IT. Но есть и другая серьёзная проблема, с которой рискует столкнуться бизнес, работая с IT. Это работа IT в подходе JSDD (Job Safety Driven Development). На эту тему уже была несерьёзная статья, теперь будет серьёзная. Заодно рассмотрим возможные выходы их ситуации.

Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи МегаБокс/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом).

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

В рамках подхода JSDD (Job Safety Driven Development) работа строится таким образом, чтобы IT-специалиста либо IT-специалистов не могли уволить. Для того чтобы специалиста (не только из IT) не могли уволить, ему необходимо либо стать незаменимым, либо создать иллюзию незаменимости. Иными словами, либо реально иметь очень высокую стоимость замены и связанные с этим бизнес-риски, либо создать такую иллюзию.

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

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

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

Что такое «bus factor»? Это количество ключевых специалистов, после потери которых работа не сможет продолжаться. Если количество таких ключевых специалистов равно единице, то просто представьте, что ваш ключевой сотрудник выходит из офиса и его насмерть сбивает автобус. Вся работа встала, что делать дальше - не понятно.

В реальной жизни автобусы людей сбивают не так уж и часто. Желание сходить в отпуск либо просто взять больничный - куда более частое явление. Вообще наше трудовое законодательство предполагает, что человек минимум один раз в год уходит в отпуск. Можно и больше раз, но один раз в год нужно сходить в отпуск минимум на 2 недели.

С какими проблемами встречается человек с bus factor равном единице, когда ему нужно идти в отпуск? Ведь в его отсутствие работа встанет. Ну, есть несколько вариантов:

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

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

Это простой и быстрый вопрос, достойный отдельного раздела. Потому, что он важный, но его очень часто, почему-то, упускают из внимания. Знаете, IT-специалистов очень легко увольнять, они не сильно цепляются за работу.

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

А если это инициатива компании? Когда увольняют квалифицированного IT сотрудника, все понимают, что рынок поглотит его за несколько недель, если сотрудник будет искать работу пассивно. Либо за неделю в случае активного поиска. Человек не останется без средств к существованию, человек не останется невостребованным, человек просто испытает небольшой стресс от смены работы.

Есть ещё вариант «мягкого» увольнения. При нем HR даётся указание не препятствовать давлению рынка на конкретных сотрудников, после чего они сами уходят. С радостью и в более подходящие им места, то есть даже стресса от смены работы не будет.

В нашей компании кроссплатформенная разработка мобильных приложений на Flutter победила нативную разработку мобильных приложений на Object-C, Swift, Java, Kotlin. Те мобильные приложения, которые мы делаем, как сопутствующую работу, являются средней сложности в нашем понимании (мессенджеры, системы электронного документооборота, работа с несложным медиаконтентом). Такое делается на Flutter быстрее и дешевле.

Как результат, в компании теперь нет отдела мобильной разработки из 4-х разработчиков и кучи проблем из-за тестирования нативной разработки под различные модели устройств. Процесс расформирования прошёл плавно и безболезненно для всех сторон.

Зачем все это здесь? Для понимания, что сильный IT-специалист никогда не будет заниматься JSDD. Ему не надо держаться за свою работу, он себе новую работу и так найдёт.

Но это не касается людей с небольшим опытом либо с низкой квалификацией. А так же людей, которые страдают от «синдрома самозванца».

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

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

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

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

Либо вы крупный интернет-магазин и к вам приходит пандемия. Сначала все пугаются, вы спешно рубите косты. Через несколько месяцев ваша IT-инфраструктура (и не только она), начинает просто захлёбываться под нагрузкой от того, что у вас количество пользователей и заказов многократно возросло.

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

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

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

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

Если мы говорим о классическом JSDD, то им занимаются не очень востребованные и квалифицированные IT-специалисты, которые вынуждены цепляться за свою работу и создавать иллюзию своей незаменимости.

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

Представителей бизнеса будут постоянно пугать срабатыванием бизнес-рисков. Для того, чтобы понять, что это иллюзия необходим взгляд сверху и взгляд сбоку. Что такое взгляд сверху? Да, бывают реальные случаи сотрудников с bus factor равном единице. Да, бывают случаи высокого технического долга и даже «технического дефолта», это больно и неприятно. Да, многие IT-специалисты могут быстро найти себе работу. Но попадая в такую ситуацию здоровые IT-специалисты ведут себя определенным образом.

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

Любые хронические либо просто затяжные негативные ситуации без положительной динамики должны вызывать вопросы. Конечно, чем больше бизнес, тем меньше скорость изменений, но у всего есть свои пределы. Например, если у вас проблемное место сайт, для которого написать аналог занимает 2 месяца, то перманентное страдание со старым сайтом на протяжении года уже должно вызывать вопросы. Если у вас проблемное место - это комплексная автоматизация предприятия со сроком внедрения новой системы 1 год, то страдание со старой системой на протяжении 3-5 лет тоже должно вызывать вопросы.

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

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

Для мира IT ситуация с иллюзиями во многом обстоит ровно так же, как и в обычном мире. Работают ровно такие же принципы и подходы. Только порог входа чуть повыше.

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

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

Здесь, как со строительством. Сарай может построить чуть ли не каждый. Одноэтажный частный дом можно спланировать на листочке бумаги в клеточку (но уже стоит задуматься, а стоит ли так сделать). Для постройки многоподъездной десятиэтажки нужен архитектор и не только.

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

В конце концов, все (ну почти) хотят спокойной жизни, ходить в отпуск и обходится без переработок. Поэтому наизвлекавшись пользы из бизнеса, такая техническая команда элементарно сбежит.

Это сложная ситуация для бизнеса, в которой достойных вариантов выхода не много. Прежде всего придётся найти более квалифицированную техническую команду. Затем, после обследования, принять решение «выкинуть все и написать заново» либо стабилизировать систему, после чего погасить технический долг, пусть даже путём реинжиниринга системы.

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

Это как с фундаментом дома. Допустим вы купили участок с готовым фундаментом. Хорошо это либо плохо? Скорее всего, плохо. Во-первых, фундамент вас ограничивает проектом дома, который вы возможно не хотите. Во-вторых, вы не знаете реальных условий заливки и качество фундамента, использовать его рискованно. Иногда проще демонтировать фундамент (дополнительные вложения и списание затрат), чем вписываться в ненужные ограничения.

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

Честно говоря это всегда неприятная и сложная ситуация. В психологии существует упрощённая модель социального взаимодействия людей под названием «Треугольник Карпмана», он же «Драматический треугольник». В нем есть роли «Жертва - Агрессор - Спасатель». Мы предпочитаем термин «Спаситель».

Почему так? Потому, что есть реальные «спасатели», которые спасают жертву обстоятельств раз и на всегда, а есть «спасители», которые предпочитают спасать жертву (одну и ту же, кстати) периодически.

Модель треугольника Карпмана, несколько упрощённая, но некоторые явления описывает достаточно точно. Например, психологию поведения «спасителя». Если мы говорим про IT, то здесь в роли спасителя будет выступать высококвалифицированный специалист с большим желанием быть нужным и выраженной жалостью к людям, что будет выливаться (только внешне, конечно) в желание помочь людям.

Спаситель будет оберегать от ошибок членов IT-команды, в том числе от получения опыта и самостоятельности. Для «спасителя» характерно подсознательное стремление замыкать все процессы на себя (хочется быть нужным), а в коллективе он имеет большой авторитет в силу своей квалификации и постоянного стремления помочь.

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

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

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

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

Мы познакомились с явлением JSDD - Job Safety Driven Development, которое может формировать у бизнеса болезненную зависимость от IT-команды (бизнес в заложниках у IT). Рассмотрели, как и почему оно возникает. Поняли, как отличить JSDD от случаев, когда есть реальные проблемы.

Так как мы смотрим на вещи с точки зрения бизнес-заказчиков, мы не сильно углублялись в технические приёмы, которые применяются в JSDD. Но с ними можно ознакомиться в статье «Как писать код, чтобы тебя не уволили?», однако вместе с этой статьёй нужно читать хотя бы статью «Почему всё ломается даже у хороших программистов?». И дело не в сложности систем, техническом долге и прочем. Дело в том, что не только инженеры (в нашем случае из IT) любят брать бизнес в заложники, но и бизнес часто пробует взять в заложники инженеров. Но об этом уже в другой статье.

Тем не менее, у нас появилась возможность посмотреть на многие процессы сверху и наметить выход из них.

Если вы дочитали до конца, и написанное было для вас полезным, то спасибо вам.

Полезные материалы по теме: