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

[MaksimusDecius]

Хорошая статья. Одна из тех, которую бизнес никогда не захочет читать, потому что не виноваты и неудобно :)

[Esei]

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

Ну, а на тему неиспользования экспертизы, я думаю, я ещё напишу.

[parakhod_1]

С одной стороны бывает и так. Не очень хорошо.

С другой стороны может быть ещё хуже если во всём слушать исключительно инженеров. Лет восемь назад меня позвали консультировать одну американскую компанию - у их андроидной команды были проблемы. С точки зрения бизнеса были проблемы, они отставали от иоса по фичам почти на код. Куча фич запихивалась как временные решения через webview (это не воспринималось как tech debt, скорее как уступка от разработчиков «ну раз уж вам так сильно надо»).

А чем была занята команда из семи разработчиков? Они уже четвёртый месяц писали супер-продвинутый логгер. Который идеально в архитектурном плане должен был логить в пятнадцать мест идеально собранную телеметрию из идеально сконструированного приложения (хоть учебник по жабе по нему пиши) которое они до того рефакторили уже полтора года.

На реальные фичи у них просто не было времени.

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

Ну я отчёт написал, конечно. Но не думаю что он кому-то понравился.

[Esei]

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

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

[parakhod_1]

Вас бы туда и не взяли. И меня бы туда не взяли бы на работу. За одно лишь употребление слова «контроль».

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

[Esei]

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

[parakhod_1]

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

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

[zgwerby]

Делайте хорошо. Плохо не делайте.
Переобуваться в прыжке - плохо. Но клиент всегда прав.
Костыли на костылях - плохо. Деньги здесь и сейчас - хорошо.

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

[Esei]

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