Айсберг IT: Почему результат успешно сданного IT проекта так плох?

IT проект завершён. Успешно сдан. Решение внедрено. Результат внедрения работает.

И это вообще не то, чего хотел заказчик.

Бывало у вас такое?

За более чем 20 лет в индустрии я наблюдал такую картину из разных ролей настолько часто, что пора признать: это, пожалуй, правило, а не исключение.

И со временем ничего не меняется. IT решения становятся лишь сложнее и запутаннее. Архитекторы создают простые абстракции над сложными технологиями. Поверх этого дизайнеры создают действительно удобные интерфейсы. Но хорошего результата добиться всё сложнее и сложнее.

Эта проблема будет рефреном проходить через всю серию статей, и мы будем рассматривать её под разными углами. Конкретно в этом разделе важно понять, что происходит с конечным результатом. Как он тестируется, как принимается и как внедряется. Где кроются грабли, и куда они бьют.

Как и ранее - начну с конца.

Люди с трудом меняют свои привычки, а бизнес с трудом меняет свои процессы.

Петрович сидит на своём рабочем месте уже 15 лет. Он привык к “старой-доброй” программе, написанной 30 лет назад. Она кривая, косая, неудобная - но он этого не видит. Он привык. Изо дня в день он повторяет привычные, уже отработанные до автоматизма, действия - и ему даже не нужно их обдумывать. Мозг экономит энергию. Петрович счастлив.

Объяснить Петровичу, что ему нужно изменить свои привычные ритуалы - тяжело до невозможности. Покажите ему самый удобный современный интерфейс - Петрович запутается в нём, как в трёх соснах и попросит обратно своего “старого-доброго” монстра.

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

Ну, а если в процесс вовлечены ещё и другие отделы, да внешние контрагенты… don’t get me started on this - инерция такой системы будет чрезвычайно велика. И даже отлично написанное ПО, замечательно решающее проблему в теории - будет ой как трудно внедрить на практике.

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

Думаете, это свойственно только Петровичу - потому, что он динозавр? К сожалению, нет. В другой компании сидит молодой менеджер Олег - и он за год уже настолько врос в свой бизнес-процесс, что ему почти бесполезно что-то там объяснять и что-то там предлагать. Тем более, что…

Ещё одна важная проблема, о которой частенько вспоминают только на этапе внедрения - что в процессе формулирования проблемы, постановки задачи, создания интерфейса и логики, разработки - никто не спрашивал ни Петровича, ни Мариванну, ни даже прогрессивного Олега: а как они вообще работают сейчас, и как они будут использовать новое ПО. Точно ли им понятно, что с этой фигнёй делать? А если это им не понятно - точно ли дело в их непроходимой дремучей тупости, или просто проектировщики чего-то недопонимают?

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

Здесь напротив друг друга лежит пара хороших, крепких граблей. Полшага влево - наступишь на одни. Полшага вправо - на другие.

Одни грабли называются “нечёткие критерии приёмки”. Ну, когда мы делаем “что-то”, что должно работать “как-то”. Программисты пилили себе код по ТЗ, вот уже пришёл дедлайн - вроде всё сделано, и менеджер проекта вспоминает, что проект-то надо не только вести, но ещё и сдавать. Идёт сдаваться - а его заворачивают. Идёт делать доработки. Возвращается. Его заворачивают.

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

А вторые грабли в этой сладкой парочке - “жёсткие критерии приёмки”. Да, представляете, это тоже может быть проблемой, да ещё какой. И чем больше проект - тем мощнее и больнее бьют эти грабли. Особенно в госпроектах и тендерах. Кто-то полтора-два года назад написал требования, они были зафиксированы в контракте и подписаны кровью. Идём сдаваться - конечный продукт полностью этим требованиям удовлетворяет, но с ним совершенно невозможно работать. Там что-то не учли, тут что-то не согласовали, да и вообще всё поменялось за это время. Заказчик рвёт на себе волосы и кричит: “сделайте же что-нибудь!!” - а ему в ответ лишь разводят руками: вот подпись, вот печать. Не имеем права. К чему это приводит - я недавно уже писал.

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

Как же пройти между этими граблями? Ооооо, это задача очень непростая. Как минимум с обеих сторон должны быть грамотные, вменяемые люди, понимающие всю сложность задачи. Действующие в духе Agile Manifesto, а конкретно пункта про “отношения с заказчиком важнее написанного контракта”. Тогда при в целом строгих критериях приёмки появляется определённая гибкость для реализации того, что реально нужно, даже если это противоречит бумажке. Подрядчик закрывает глаза на то, что ему надо реализовать что-то, не вошедшее в ТЗ - а представитель заказчика закрывает глаза на то, что где-то работает не так, как прописано в критериях приёмки. Но очень важно, чтобы это была обоюдная слаженная работа обеих сторон - иначе грабли неизбежны. Соблюсти грамотный баланс бывает неимоверно трудно.

Disclaimer: Я здесь намеренно опускаю сложную нутрянку о юнит-тестировании, функциональном, регрессивном, исследовательском, нагрузочном, на отказ и т.п. Это отдельная большая тема. Единственное, что считаю обязательным упомянуть - что нагрузочное тестирование надо делать обязательно. Какое именно и зачем именно - другой вопрос.

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

Совсем без тестирования или с минимальным тестированием левой пяткой - неизбежно получим проблемы на этапе внедрения. Когда ВНЕЗАПНО оказывается, что результат сырой, кривой-косой, постоянно падает, а когда не падает - то работает через раз. И даже формально может удовлетворять критерию приёмки по количеству дефектов - но работать с таким конечным продуктом будет очень неудобно, трудозатратно и стрессово.

Чрезмерное же тестирование может выродиться в тестирование ради тестирования. Это часто ходит рука об руку с жёсткими критериями приёмки: когда важность работающего результата уже давно потерялась за формализмом. Когда тестировщик из-за сдвига отступа на 2 пикселя заворачивает на доработку панель администратора, в которую один-единственный пользователь заходит раз в месяц - а при этом основной сценарий пользователя содержит грубейшие ошибки. Полностью при этом соответствуя требованиям.

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

Легче сказать, чем сделать. Как и в большей части происходящего в реальности.

Как видите, даже если на предыдущих шагах разработки всё было сделано хотя бы неплохо и решение уже фактически готово - можно нехило так походить по граблям, получив в результате немало травм и не вполне рабочий результат. Плохо протестированный, не соответствующий ожиданиям, с перерасходом времени и бюджета - и нафиг не нужный конечным пользователям.

А что если и на предыдущих этапах были допущены ошибки? Там ведь тоже немало граблей!

Но об этом - в следующих сериях.