Если поработать в ИТ-индустрии с десяток лет, то уже интуитивно улавливаешь, когда ситуация на проекте начинает выходить из-под контроля. Если же такое чутье у вас пока отсутствует – обратите внимание на следующие моменты, которые можно считать первыми тревожными звоночками.
1. Все зависит от того…
Если спрашиваешь сотрудника, как работает тот или иной компонент, или где находятся определенные данные, он пускается в объяснения, которые начинаются с фразы «Всё зависит от того…»
Например, я спрашиваю, как проверяется пользовательский пароль, а сотрудник выдает мне что-нибудь вроде: «Все зависит от того, зарегистрировался ли пользователь до 2001 года. Если так, то нужно вызвать систему genesis logon, а после 2001 мы уже переключились на active directory. Но это если пользователь не был клиентом той компании, что мы купили в 2005. В таком случае, нужно вызвать «миграционный» протокол LDAP, который они тогда прикрутили. Этот протокол использует Netscape LDAP, поэтому понадобится библиотека JNDI, кстати, мы ее пропатчили, чтобы справиться с некоторыми багами. Ну а если пользователь – админ, то мы храним его учетную информацию в базе данных по персоналу. Чтобы достать данные оттуда, нужно выполнить поиск по ODBC».
Все понятно: накопился технический долг, неэффективные решения никто не дорабатывал, а вот теперь длинный список «всё зависит от того…»
2. Вася Пупкин
Здесь речь пойдет о системе или компоненте, в которой разбирается только один человек. Такую ситуацию можно было бы саркастически назвать «ипотечно-ориентированное программирование» (кодим, пока не отбит кредит за квартиру), но иногда она возникает из-за банальной апатии. К сожалению, некоторые системы кажутся такими скучными, что работать над ними никто не желает, так что ее просто забрасывают, полностью пренебрегая всякой техподдержкой. Сложности начинаются всякий раз, когда «эту задачу может решить только Вася Пупкин», а на деле оказывается, что и Вася-то уже с трудом представляет себе систему. Он может выполнять лишь минимальную работу, чтобы она хоть как-то фурычила.
На самом деле подобные проблемы возникают лишь с теми старыми системами, которые по-прежнему важны для организации. В противном случае старую систему можно просто отключить. Но если она решает конкретные задачи, то весьма вероятно, что рано или поздно ее придется усовершенствовать, а сделать этого никто не сможет – Вася-то давно уволился.
3. Супергерой
Такая проблема с поддержкой во многом перекликается с предыдущей, но речь уже идет не о том, что система отказала, а о том, насколько катастрофическими последствиями это чревато… Как вы понимаете, последствия всегда катастрофические. Если система отбилась от рук, то мы вспоминаем, что спасти нас может лишь один толковый парень – наш местный супергерой. Разумеется, когда случилось ЧП – его рядом нет, но все знают, что лишь он способен все исправить.
Когда случается катастрофа, мы лихорадочно пытаемся с ним связаться: звоним на домашний, на мобильный, стучим в Твиттер. Его нигде нет. Что делать? Мы обречены. Казалось бы, все пропало, и тут… дозвонились! Героя нашли, но он сейчас на пляже в Рио. Выйти в сеть и оценить ситуацию он не может. Однако он не теряется: можно по частной виртуальной сети подключиться к серверу в Гамбурге, создать SSH-туннель через датацентр в Сан-Франциско, а оттуда выйти на корпоративный сетевой экран… и вот, он уже здесь! Всего за несколько минут умелец диагностирует потенциальную проблему. Людей вызывают на командный пункт, раздаются приказы, бюрократия игнорируется, изменения делаются по-быстрому. Наконец, наш герой объясняет суть проблемы, говорит, что все сложно, потребуется время, но он эту задачу решить сможет. Никто, в общем-то, не представляет, о чем он толкует. За полночь систему удается реанимировать, все хлопают друг друга по плечам – мы команда, мы выдюжили! Но, самое главное, в ножки кланяемся нашему герою. Эх, что бы мы без него делали…
Все благодарят спасителя, а потом забывают о нем примерно на месяц, ровно до того момента, когда вновь случается такая же катастрофа. Проблемы в таких системах так и не удается окончательно исправить. Может быть потому что команда техподдержки не обладает для этого достаточной квалификацией, либо просто не имеет на это времени – слишком занята, не до подвигов.
4. Канцерогенный прототип
Такая система начинается с классной идеи, обладающей большим потенциалом. Для оценки потенциала создается демо-версия/пилотная версия/прототип, и складывается впечатление, что потенциал вполне понятен. Компания с энтузиазмом запускает проект в производство – руководство уже строит наполеоновские планы. Инженеры, реализовавшие прототип, конечно, польщены такой высокой оценкой своей работы, однако остаются сдержанными – ведь это всего лишь демо-версия.
Технари четко говорят об этом команде. Система еще нежизнеспособна, она плохо масштабируется, в ней еще нужно доделать механизм обработки исключений, журналирование отсутствует, мониторинг хромает и т.д., и т.п. Однако никто к ним не прислушивается, начальство просто обещает «попозже» выделить команде время на всю эту доработку.
«Попозже» так и не наступает. Система пошла в работу, поэтому постоянно приходится добавлять новые фичи. Она стремительно растет и уже начинает влиять на работу других систем. К сожалению, из-за многочисленных шероховатостей добавление новых возможностей протекает неаккуратно, технический долг накапливается.
Решение
Как и большинство проблем в ИТ-сфере, технические проблемы обусловлены ошибками управления. Все вышеперечисленные симптомы возникают из-за ряда проблем менеджмента. Однако, корень любой проблемы – это нежелание менять статус-кво, повышать качество разработки и брать ситуацию под контроль. Определите, какой уровень качества является для вас минимально приемлемым, и не опускайтесь ниже него.
Источник: Энди Хеджес
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.