Comments 12
Хорошая статья. Одна из тех, которую бизнес никогда не захочет читать, потому что не виноваты и неудобно :)
Максим, большое спасибо за оценку!У меня всё же есть надежда, что взор бизнеса упадёт на одну из таких статей (если их будет достаточно много), и хотя бы один из руководителей топ-уровня, пусть даже не большой компании, попытается разобраться в том, о чём я написал, и от этого станет немного легче всем - и ему самому, ведь IT станет работать быстрее и качественнее, и его подчинённым всех уровней, ведь их начнут понимать и, соответственно, к их мнению начнут прислушиваться.
Ну, а на тему неиспользования экспертизы, я думаю, я ещё напишу.
С одной стороны бывает и так. Не очень хорошо.
С другой стороны может быть ещё хуже если во всём слушать исключительно инженеров. Лет восемь назад меня позвали консультировать одну американскую компанию - у их андроидной команды были проблемы. С точки зрения бизнеса были проблемы, они отставали от иоса по фичам почти на код. Куча фич запихивалась как временные решения через webview (это не воспринималось как tech debt, скорее как уступка от разработчиков «ну раз уж вам так сильно надо»).
А чем была занята команда из семи разработчиков? Они уже четвёртый месяц писали супер-продвинутый логгер. Который идеально в архитектурном плане должен был логить в пятнадцать мест идеально собранную телеметрию из идеально сконструированного приложения (хоть учебник по жабе по нему пиши) которое они до того рефакторили уже полтора года.
На реальные фичи у них просто не было времени.
А в той компании начальство было ультралиберальных взглядов, поэтому в каждой команде была полная демократия. И инженеры (андроидные) выбрали тот путь, который они считали верным.
Ну я отчёт написал, конечно. Но не думаю что он кому-то понравился.
Спасибо за комментарий, очень ценно, что это - жизненная история.
Я бы тут со своей стороны отметил, а точнее - разделил бы «ультралиберальные взгляды» и отсутствие управленческого контроля. Я не могу сказать точно: меня там не было. Был ли это ультралиберализм или просто руководство не очень хотело погружаться в то, чем заняты инженеры - а это, в свою очередь, управленческий риск.
Доверять инженерам, конечно, нужно, но и одним глазом приглядывать за тем, что они реально делают и какая у этого бизнес-ценность, тоже необходимо. Иначе они в построении своих «космических кораблей» очень сильно могут оторваться от бизнес-видения руководства и целей компании.
Вас бы туда и не взяли. И меня бы туда не взяли бы на работу. За одно лишь употребление слова «контроль».
Там история именно в стиле управления была, руководство свято верило в демократию на всех уровнях. У них даже самые мелкие решения принимались голосованием.
Если это работало и приносило прибыль, то я снимаю шляпу: управленческие навыки такого уровня «бирюзовости» мало у кого есть.
Начиная с некоторого размера любой бизнес превращается в говно, которое не тонет, и надо крайне сильно постараться чтобы его утопить.
Я не знаю как у них было раньше, но на тот момент они занимали приличную долю в цифровизации американской системы школьного образования (я на называю компанию, но вычислить при желании можно), и откровенно катались как сыр в масле, даже при достаточно поганом качестве самого продукта.
Делайте хорошо. Плохо не делайте.
Переобуваться в прыжке - плохо. Но клиент всегда прав.
Костыли на костылях - плохо. Деньги здесь и сейчас - хорошо.
Проблема не в том, что эти банальности никто не знает.
Проблема в том, что реальный заказчик живёт в одном мире. Разработчики живут в другом мире. И эти миры редко когда пересекаются, а мир клиента у руководства превалирует над миром разрабов. И мало кто может интегрировать первое во второе.
И вот тут вы поднимаете очень важный и злободневный вопрос о подготовке IT-управленцев, которые должны не просто ходить и следить за инфраструктурой и за тем, чтобы ничего не падало, а контролировать ресурсы, заботиться о своей команде, для бизнеса подсвечивать все «скрытые места» - зоны, где IT может принести дополнительную ценность или предотвратить риски.
Ведь ключевая задача IT-директора - донести до бизнеса важность работы инженеров, аналитиков, тестировщиков и всех причастных. Нужно изменить сложившееся у топ-менеджмента впечатление, что IT - это лишь обслуживающий персонал, а бизнес (как заказчик со своими требованиями) - «истина в последней инстанции». При этом апеллировать к несостоятельности отдельных требований бизнеса не только можно, но и нужно - в конструктивном ключе, с предложением альтернативных решений.
Вы абсолютно правы: на рынке пока не так много талантливых управленцев, способных интегрировать одно в другое. Именно в этом и заключается настоящий IT-управленческий талант - быть проводником из мира "цифры" в мир бизнеса, ну или наоборот)
К техдолгу нужно относиться с "терпением", как это делает бизнес. Если бизнесу не надо, значит и тебе не надо, будь проще, это не твой код, а бизнеса. А если все таки хочется сделать свою жизнь на проекте более комфортной, то нужно научиться вшивать в оценку на выполнение продуктовых задач время на погашения технического долга. Ну и естественно с бизнесом надо уметь говорить о техдолге, продавать необходимость его погашения.
Добавлю от себя. В банковской сфере топ-менеджмент полагает, что контролирует финансовый долг: в конце концов это он подписывает разрешение на его увеличение, или стоит за мерами по урезанию расходов. То есть о том, какие финансовые долги у организации, топ-менеджмент доподлино знает из отчетности. В их головах прочно укореняется: то о чем я не знаю, не существует... А кто-нибудь приходит к ним с отчетами о техническом долге?..
Есть тех.долг, а есть ТЕХ.ДОЛГ. Без костылей жить не получится, но надо знать меру. Нельзя размножать плохие решения, но изолировать их. Если у вас личный кривой аналог кафки, который используется в 100 мест, то это полбеды - если у вас 100 разных кривых аналогов кафки, то это фатально. Если у вас есть 10 говносервисов и вы пишите 11 такой же, то в ближайший год вы напишите еще 10. И это больше зависит от разработки.
Отдельно скажу про код ревью: пока код не влит его менять супер дешево. Какой нить мр на 1000 строк можно за день полностью переписать. После влития уже за неделю. После релиза уже месяц. Так что на код ревью надо реально делать ревью.
Технический долг — это не IT-проблема. Это управленческий кредит, который никто не собирался возвращать