Зарисовка из жизни IT~BP: Самоорганизация в IT

У Рейнвотера Дж. Ханка есть интересная книга «Как пасти котов». Она написана для программистов, которые собираются управлять другими программистами. В названии книги есть очень красивая и точная метафора. Если вы возьмёте орду котов, то они не будут заниматься самоорганизацией, вместо этого они разбредутся кто куда и будут делать каждый что-то своё. Самоорганизация в IT выглядит так же. О том, как это бывает в жизни и почему происходит, написано ниже.

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

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

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

Теперь посмотрим, что может произойти в реальной жизни.

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

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

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

И вот уже в компании есть не меньше 4-х клиентских сайтов, несколько самописных ERP-систем, самописная же CRM, плюс какие-то системы на 1С. Знания же о том, в чем смысл интеграции между 1С и самописными системами, командами разработки утрачены. Все это как-то работает, но есть нюансы, как в знаменитом и пошлом анекдоте.

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

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

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

Сколько таких инцидентов происходит у компании в месяц никто сказать не может. Статистику никто не ведёт. Зато известно, что пользователи ERP и CRM дублируют все данные, которые вводят в систему, в Excel. Потому, что они верят Excel, а внутренним система — нет, оттуда данные исчезают, да и работает оно не всегда.

Несложно понять, что в компании IT пользуется заслуженной любовью, и напрямую общаться с разработчика стало нельзя не просто так.

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

Сразу стоит сказать, что команда 1С нормально общается с пользователями и раз в 10 меньше другой команды, больших страданий пользователям не доставляет. Особых проблем с 1С не возникает, доработки идут своим чередом. Команда «взрослая», немного сопротивляются изменениям, но на диалог идут, чужую точку зрения слышат.

Как выглядит интеграция между 1С и самописными системами. Команда 1С говорит, что они только дают API для чтения из системы и даже не знают, кто и как этим пользуется. Что говорит основная команда разработки? Они знают, что есть 1С, они знают, что есть какая-то интеграция. Но совершенно не знают зачем она вообще нужна и как выглядит.

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

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

Из этих же веток, путем объединения, собирается релиз и отправляется на тестовый стенд, где релиз проверяется тестировщиками. По результатам тестирования пишется отчёт об ошибках и принимается решение, можно ли выпускать релиз с такими ошибками (может у них вероятность возникновения 0.0001%, да и то у особо умелых пользователей). Если релиз выпускать нельзя, то он оправляется на доработку, обычно требуется несколько итераций тестирования, они заранее закладываются в план.

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

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

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

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

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

Для команды это была рядовая ситуация, какой-то проблемы в этом они не видели. Более того. Первоначальную доработку мог сделать один программист, все поправить второй, а заново все исправить — третий. Так систему и шатало из сторону в сторону.

Кстати, нормальным распределением задач между разработчиками никто не занимался. На самом деле каждый брал себе то, что хотел. Оценок тоже не было, а на сроки все уже забили. Как результат, на ком-то была 1-2 задачи, на ком-то 10-20, когда и что попадёт на продуктив никто не знал.

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

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

В целом, у команды даже не было бэклога (списка задач, которые нужно сделать). Когда у людей спросили, почему так, то они ответили, что обычно они записывают те задачи, которые сейчас непосредственно делают. А остальные они запоминают просто.

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

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

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

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

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

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

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

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

На самом деле, в IT очень много взаимосвязанных процессов, причём очень часто одно без другого не работает. Они даже сведены в многотомные справочники для того, чтобы можно было осуществлять IT-трансформацию. Один ITIL/ITSM по своему объему чего стоит, а он один из самых простых и доступных.

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

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

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

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

Мало знать «лучшие практики», нужно еще понимать, как эти практики взаимодействуют друг с другом. В области IT есть дополнительная сложность, нужно еще уметь управлять культурой производства.

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

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

То, что работает у одних, не обязано работать у других. Слепое и неполное копирование результата не даёт.

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

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