Just do it: истории из жизни, советы, новости, юмор и картинки — Горячее, страница 2

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

Ни трейс, ни лог не выдали никаких симптомов. Отладка в модулях, где в основном сосредоточена бизнес-логика, показала, что всё работает добросовестно. А модули, которые работают со входными данными, тоже не признались, что у них есть баги. Где-то пять часов отладки спустя, я начал что-то подозревать. Я уже очень долго не мог найти объяснение происходящему. В мыслях, эмоционально, я возвращался в моменты, когда я только начинал программировать, и очень часто попадал, как мне казалось, в тупик. И это ощущение меня убеждало в том, что ошибка должна быть самой идиотской, которую только можно придумать. Ситуацию не проясняла даже отладка по шагам. Я уже говорил тебе, что такое безумие? Безумие — это точное повторение одного и того же действия раз за разом в надежде на изменение. Это. Есть. Безумие. Похрен! Я начал разговаривать сам с собой, и вдумчиво читал код, прослеживал модификацию данных, объяснял себе, что делает сейчас код функции, на которую я смотрю. Буквально, читал каждую строчку и интерпретировал ее, а потом в дебаггере сверял, что я все правильно интерпретировал.

И вот, зашел я в который раз в функцию, в самый грязный модуль, который занимался стягиванием данных из базы в бомбическую иерархию классов, которая, считай, в ядре бизнес-логики как ложка гуано мамонта в бочке с вискарем. Я вернулся в одну из функций, которую я всегда пытался как можно быстрее в проскочить в дебаггере, потому что глаза начинали кровоточить от нагромождения if else и кошмарного кода с нарушением всех возможных принципов программирования, и наверное, парочки международных конвенций. Но я понимал, что в этот раз все нужно делать без исключений и придется строчка за строчкой объяснить, что в этой функции происходит. Где-то на половине функции, на строке с номером где-то около 1700, я начинаю чувствовать, что что-то не так. То ли я обговорился, то ли потерял мысль. Как я могу потерять мысль, если я просто интерпертирую то, что уже написано? Присмотревшись к коду, зашёл на точку останова повыше, и оказалось, не показалось. Увидел я очень интересную, мать вашу, локальную переменную. Локальную переменную, #!&@, с именем, которое идентично имени поля класса, за исключением префикса к полям "m_"! По факту, логика обработки была правильной, но вот для одного случая, была маленькая, такая, ошибочка. Для одного действия, вместо чтения поля класса, нужно было читать эту локальную переменную-самозванца. То есть другими словами, для фикса нужно было "всего лишь" удалить две буквы! Как удачно получилось, что код настолько старый, что пережил ни одну миграцию на новую систему версионирования и просто так теперь не узнать, что за гений это сделал!

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

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

P.S.: технического долга много, и его разрешают ликвидировать, только если это блокирует выполнение какой-то бизнес задачи. Например, к этой либе подпустили человека только через год, когда начали работы в рамках задачи по увеличению быстродействия.

Показать полностью

[моё] IT Программирование Работа Длиннопост Текст Just do it Отладка Безумие Ответ на пост

who.user

Just do it⁠⁠

3 года назад

Just do it Спорт Похудение Лишний вес Тренировка Фитнес Диета Здоровье Видео

avolsed

ИТ-проекты пикабушников

ИТ Сопровождение: выжать максимум эффективности, сокращая затраты, и не потерять людей(и себя)⁠⁠

3 года назад

Приветствую всех, кто решил прочитать пост, однако сразу хочу предостеречь крутых ИТ-шных гиков о том, что глубоких технических изысканий здесь не будет(это на случай, если кто – то захочет “закидать помидорами”/накидать дизлайков, например, в связи с тем что тема не раскрыта по причине отсутствия кода по той или иной автоматизации или роботизации).

Мой пост будет больше интересен руководителям отделов ИТ сопровождения, или проектным менеджерам, перед которыми будет стоять задача по сокращению затрат на ФОТ.

Также оповещаю о том, что мой пост НЕ является рекламой, чтобы плохого никто не думал😊

Пару слов обо мне - являюсь обычным ИТ менеджером среднего звена, специализация – выстраивание работы ИТ структур: в основном, структур ИТ сопровождения(Системные администраторы(серверная часть, телеком, операционные), администраторы баз данных(разные конфигурационные единицы), тестировщики, разработчики по инцидентам. В свое время управлял отделом разработки, архитекторами

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

Вижу разные стадии, в которых могут находиться структуры ИТ сопровождения:

1.”все горит и пожарит”: в этот момент бизнес буквально молится на то, чтобы кто – то смог решить проблемы, что мешают ему жить(прямая потеря денег из – за неэффективных процессов ИТ)

2.”хочется что – то еще”: как только пожары потушены, появляются многочисленные “хотелки” о том, как улучшить сервис

3.”ДОРОГО!!!”: пожары практически забыты как сущность, и начинаются “игры разума” в сторону попыток сокращения штата ИТ сопровождения

Об этом “ДОРОГО!!!” и хотел бы поделиться мыслями с Вами. При этом, важно всегда балансировать между понятиями об эффективном ИТ менеджере:

А)ИТ стратегия следует из стратегии компании(но понятно, что не всегда это возможно, зачастую у компании нет стратегии…)

Б)назначенные ЛПР-ы в бизнесе, влияющие на судьбоносные ИТ решения, могут быть временщиками, принимающими бездумные решения, последствия которых придется кому – то пожинать

В)сокращение опытных людей, владеющих обширной экспертизой и опытом работы в этой конкретной организации может нанести непоправимый ущерб организации

Г)сократить затраты при помощи увольнения сотрудников – легко; сократить затраты таким образом, чтобы не порушились процессы, не снизилась эффективность – задача нетривильная

Д)сокращать можно экстенсивно(работа никуда не денется, просто ее нужно будет делать оставшимися сотрудниками) – и здесь есть предел; сокращать можно интенсивно(при помощи современных технологий(автоматизация, роботизация и др.) или пересмотра процесса в сторону его упрощения – и здесь также есть предел

И важно понимать, что этот предел ЕСТЬ.

В этой связи становится особо важным иметь критическое мышление, обдумывать всю обратную связь, которая касается “ДОРОГО!!!”, быть способным вступать в диалог, разбивать фактами необоснованные желания оппонента сократить штат, если есть понимание что уже некуда. Акцентирую внимание на том, что мероприятия по оптимизации могут уже быть выполнены(как экстенсивные, так и интенсивные), а “хотелки” по сокращению персонала могут не уйти. Хочу отметить, что не рассматриваю случай смены организации в данном посте – нет, моя цель иная: представить свое видение о том, как поступать в таких случаях. Помимо этого, получить в комментариях обратную связь от более опытных в плане умения сокращать затраты ИТ сопровождения коллег, а также их точку зрения концептуально по поводу данного поста, подискутировать.

Итак, переходим к практической части. Есть задача сократить штат ИТ сопровождения, например, администраторов баз данных 1С.

Предлагаемые мероприятия:

1.исключение дублирующих процессов, единая точка ввода информации

2.выявления потенциала и последующая автоматизация процессов ИТ сопровождения(например, автоматическая выдача прав пользователям на основании матрицы должностей в разрезе выполняемых функций)

3.роботизация(например, сверок при сдаче отчетности из Бухгалтерии предприятия)

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

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

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

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

8.устранение узких мест, вроде неэффективной архитектуры обменов информацией между базами данных(например, внедрение Кафки)

9.запрос на пересмотр времени предоставления услуги(к примеру, было 24*7, а достаточно 16*7), показав стоимость ИТ сопровождения в каждом временном промежутке(9 – 18, 18 – 1, 1 – 9)

10.запрос на модернизацию старого ПО(если имеется старая конфигурация/платформа, на базе которой нельзя автоматизировать процессы ИТ сопровождения)

11.проведение жестких переговоров, исходя из которых стоимость ИТ сопровождения сокращается исключительно после отработки мероприятий, указанных выше, а также просчет целесообразности отработки этих мероприятий(стоимость внедрения должна окупаться в адекватные сроки). Если “эффективный менеджер” от бизнеса не принимает аргументы, предложите ему найти на рынке более дешевые услуги в сравнении с вашими, или же сами сравнитесь с рынком(вы можете ответить, что у вас уникальное нетиповое ПО, и сравниться с рынком невозможно, и таки отвечу: это еще один аргумент для того, чтобы обеспечить отказоустойчивую структуру ИТ сопровождения, потому как если растерять штат – на рынке специалистов не будет; а сравниться с сопровождением типовых сервисов легко, и чем больше организация/штат ИТ, тем более дешевый сервис в сравнению с рынком нужно уметь оказывать, иначе зачем нужен внутренний ИТ, если асутсорс на внешнем рынке стоит дешевле…). Еще раз: сначала выполнение мероприятий, что позволит сократить трудозатраты ИТ сопровождения(а это в том числе бюджеты на проекты по автоматизации/роботизации, время на реализацию проектов и подтверждение эффекта, и прочее), и только потом – сокращение персонала. “Эффективный менеджер” не принимает и аргументы, и сравнение с рынком – настаивайте на том, чтобы поставил свою подпись под рисками(их можно оцифровать: например, увеличение на Х количества инцидентов, аварий, конкретное снижение уровня сервиса(например, скорость реакции на запросы будет не час, как ранее, а три)). Конечно же, чем сильнее роль ИТ в организации, тем проще аргументировать позицию.

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