Трансформация или чемодан без ручки (часть 3) «Костыли» в продукте: как бизнес и разработка идут к трансформации

Хочу продолжить свои размышления на тему технический трансформаций ИТ продукта

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

Именно вопрос сотрудников является краеугольным камнем успеха не только трансформации, но и большинства других вопросов в ИТ.

Итак про специалистов, более того про ключевых технических специалистов компании.

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

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

Почему техническому специалисту говорить о проблемах существующей системы страшновато, да и что говорить просто опасно? Да потому, что именно этот специалист разрабатывал эту систему и именно он ответственен за ее теперешнюю реализацию.

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

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

- шаг 2: бизнес приходит и говорит разработке, что необходимо в кратчайшие сроки, (именно в кратчайшие сроки , потому что нужен довольный клиент, деньги заплачены, премии хочется и тд…) реализовать этот функционал. При этом мы все знаем, что в Jira или аналогичных системах, уже висит куча требований по доработке, устранению ошибок и прочих задач от бизнеса, не говоря о том, что к примеру и систему балансировки нагрузки и систему логирования нужно как минимум реализовать, если она не реализована, ну или хотя бы систему мониторинга разработать, но это все задачи, которые как будто нужны только техническому департаменту. А задачи с наивысшим приоритетом какие? Правильно, те за которые компания получает реальные деньги.

- шаг 3: Встреча у лица принимающего решение или у владельца. С одной стороны технический департамент, с другой стороны бизнес. Технический департамент, говорит, что если не оптимизировать код, или не разработать систему мониторинга, через 5-6 месяцев система гарантированной получит технические проблемы и не сможет качественно функционировать. А бизнес отвечает, что 5-6 месяцев это очень далеко и что вот сейчас нужно быстренькое реализовать эту фичу, и потом, конечно они будут только «ЗА» если технический департамент начнет заниматься профилированием системы или другими своими техническими задачами. Более того они клянутся. что запрос на эту фичу самый последний, распоследний и что они год (утрирую) не будут приходить с новыми запросами. Знакома вам такая ситуация? Ну тогда вы точно знаете какое решение принимает ЛПР (лицо принимающее решение) - конечно же немедленно реализовать запрашиваемый функционал.

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

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

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

Но вернемся к ключевым сотрудникам, и тут я обращаюсь скорее к владельцам бизнеса и ЛПРам.

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

Время разрушительно и повлиять на это нельзя.

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

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

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