За одного битого двух небитых дают. Часть 2

Проблемы стали расти как снежный ком. Они больше не купировались на нижнем уровне, а летели прямиком к руководству. С программой тоже начался ад. Не секрет, что УТ 11 — конфигурация весьма специфическая. После древней, но понятной ТиС 9.7, которая стояла там раньше, глухое недовольство пользователей было абсолютно ожидаемым.
 
Контора бурно росла, появлялись новые люди. Меня они видели впервые, поэтому быстро предложили руководству: «А давайте позовём независимый аудит?»
 
В качестве «независимого светила» нашелся ведущий преподаватель местного учебного центра «1С», обвешанный сертификатами по самое не балуйся.
 
На встрече он разнес меня в пух и прах: «Всё написано не по методикам! Конфигурацию тупо изуродовали! Для чего это сделано? Зачем?» А я сидел, обтекая, и мотивированно ответить мне было нечем…
 
К счастью, собственники бизнеса оказались парнями хоть и простыми, но далеко не глупыми. Они предложили проверить теорию практикой: «Берем два компьютера. На один ставим "изуродованную" программу автора, на второй — чистую, но настроенную по методике эксперта».
 
«Светило» с темы технично съехало — мол, не барское это дело. В итоге оба стенда я собирал сам. Результат оказался предсказуем. Вердикт вынесли в мою пользу: «Косяки у автора есть, не без этого. Но в штатной "коробочной" версии вообще финиш — мы там соберем очереди как в мавзолей, а то, что сейчас делается за день, будет занимать неделю».
 
Когда мы вышли покурить с Сашей, я не выдержал и упрекнул его: «Чего ты сидел и молчал, пока меня ссаной тряпкой по морде возили? Обидно вообще-то. Столько впахивал, делал как для себя!»
 
И тут Саша выдал абсолютно резонную вещь, которая перевернула мое понимание ИТ-архитектуры. Он сказал, что не молчал, а слушал. А то, что я делал «как для себя» и не ставил их в известность — это огромная ошибка.
 
«Во-первых, мы понятия не имели, что в программе было изначально, а что добавил ты. Во-вторых, ты не владелец бизнеса и смотришь со своей колокольни. Максимум, что ты можешь потерять  — это сумму в месяц. Все остальные издержки лягут на меня. Ты же не будешь кормить моих детей и платить зарплату моим сотрудникам?»
 
Мне нечего было возразить.
 
С тех пор правила игры жестко изменились. Теперь все идеи, проблемы и доработки идут строго через верх, санкционируются руководством и только потом спускаются вниз. Такой подход позволяет директорам четко видеть: окупаются ли доработки и использует ли их персонал.
 
И теперь на классическое нытье линейщиков: «А тут у нас… Это… Того… Не работает!» — у руководства сразу готов ответ: «Вам под эту задачу неделю назад кнопку вывели и инструкции на почту скинули. Почему не пользуемся?»
 
Это гораздо лучше ситуации, когда сотрудники бегут жаловаться начальству, а руководство косо смотрит на админа, который «изуродовал» систему.
 
Но самый главный мой косяк был в другом: я вовремя не донес до руководства истинное положение дел на низах. Пока я героически тушил пожары в одиночку, у боссов была иллюзия, что проблем нет — ни с людьми, ни с процессами, ни с софтом. А когда при масштабировании всё это разом выплеснулось наружу, на меня вылили ушат холодной воды, и оправдываться пришлось мне.
 
Как дела обстоят сейчас:
 
1️⃣ Тотальный учет: Каждое обращение тщательно фиксируется, систематизируется и раз в месяц ложится на стол собственникам с моими выводами.
 
2️⃣ Платная поддержка: Все заявки теперь оплачиваются отдельно, и я не боюсь обсуждать их с бизнесом.
 
3️⃣ Разделение логики: Там, где виной человеческий фактор, руководство включает материальную мотивацию (штрафы/премии). Там, где можно помочь технически — я пилю доработки.
 
👆 Главный урок, который я вынес: всё, что вы делаете для бизнеса (неважно, на фрилансе или в штате), должно учитываться, документироваться и согласовываться наверху. У руководства должна быть полная картина. Иначе однажды бизнесу откроется весь пласт накопившихся проблем, а крайним сделают вас — просто потому, что вы замкнули всё на себя и вовремя никого не предупредили.