Своя игра
Автор
Александр Башкиров
Бизнесу важен результат в поставленные сроки и за определенные деньги. Все остальное — от лукавого.
Скажем честно: мы все, ИТ-специалисты, привыкли работать в режиме управления требованиями. Это просто и понятно: заказчик (не важно, внешний или внутренний), система (комплекс, программа, сервер), требования, поиск решения (проектирование), реализация...
Все хорошо и стройно до первого большого релиза. Когда удивленный заказчик говорит, что вообще-то он хотел совсем другое, и его не так поняли, и у системы нет «вау-эффекта». Между тем, все строго по ТЗ — ни шагу в сторону. Знакомая картина? Что же, давайте поговорим об этом.
Начнем с того, что ТЗ обычно (но не всегда) пишут плохо. То есть существует две крайности: ТЗ от заказчика и ТЗ от исполнителя (опять-таки, в данном контексте не очень важно, внешний или внутренний исполнитель). Когда ТЗ пишется исполнителем, оно обычно «затачивается» под какую-либо имеющуюся или же известную разработчикам систему, со всеми вытекающими отсюда последствиями. А последствия могут быть как позитивными, так и негативными. Позитивные последствия состоят в том, что по известной системе ТЗ писать легко и в какой-то мере — приятно. Негативные — в том, что ТЗ, написанное «под систему», обычно опирается только и исключительно на возможности системы и, если необходимо что-то сверх — то обычно это что-то старательно обходится.
ТЗ от заказчика — это, вообще говоря, совершенно особая песня. К сожалению, обычно именно такие ТЗ представляют собой пример непроработанности и неструктурированности. Нет, исключения бывают, конечно, но, повторюсь, общее правило гласит: ТЗ от заказчика — это в лучшем случае набор требований, и не более. Так получается потому, что заказчик порой сам не понимает, чего хочет... Знаете, какой самый любимый метод написания подобного рода документов? Он очень простой: делается краткое концептуальное описание системы, затем рассылается по подразделениям, каждое из которых должно сформулировать свои требования. Потом эти требования хорошо если проверяются на непротиворечивость... чаще, кстати, не проверяются. Просто собираются в один файл, к нему прикладывается упомянутый выше бриф — все это называется «Техническое задание» и отправляется поставщику (или поставщикам) решения. Все это здорово, конечно. До тех пор пока не понимаешь, что в присланном документе описано как минимум несколько систем. То есть каждое подразделение ожидает увидеть нечто свое. По сути, данный момент и является ключом ко всей проектной деятельности — потому что именно тогда возникают ожидания от решения.
Страшнее кошки зверя нет
Что же такое ожидания? Это, с одной стороны, очень простая вещь — то, чего ждут. С другой — очень сложная вещь. Потому что она практически не формализуема. Можно сколь угодно долго описывать аспекты ожиданий, но... они останутся всего лишь аспектами. Как перевести ожидания в требования? Особенно с учетом «милого» нюанса, состоящего в том, что ожидания на каждом уровне иерархии — свои. Например, сотрудник предполагает, что новая система позволит ему автоматически получать данные о клиенте по какому-либо понятному идентификатору. Руководитель отдела — надеется, что система представит ему отчеты, на основании которых он будет делать вывод об эффективности сотрудников. И наконец, операционный директор ждет от системы автоматизации процессов и возврата инвестиций, а в перспективе — увеличение прибыли за счет оптимизации времени работы подчиненных и, как следствие, повышения их эффективности. Это, конечно, не прямо противоположные вещи, но не однородные — точно. Соответственно, работая с ожиданиями, надо учитывать такое их каскадирование, в противном случае может получиться ситуация тотального неприятия.
Как работать с ожиданиями? Для начала — ознакомиться с требованиями, которые предъявляются к разрабатываемой системе. Как правило, в том или ином виде ожидания там присутствуют. Правда, как уже говорилось выше — для каждой категории они свои. Более того, требования (и ожидания) отдельных пользователей могут быть вообще уникальными. После — составить таблицу, где распределить требования по группам (например, «требования к интерфейсу», «требования к производительности», «требования к дизайну»). Обычно после проведения подобной процедуры вырисовывается определенный контур системы — формируется представление о том, как система может выглядеть, какие функции должна выполнять и т. д. Далее можно выделить три основных категории, куда попадают требования: первая — это требования, которые ложатся в канву продукта. Они в общем понятны и в большинстве случаев перекочевывают в приснопамятное техническое задание или без изменений, или с минимальными изменениями. Вторая категория — требования, которые по той или иной причине не могут быть реализованы никогда. С ними следует работать особо: такого рода требования — потенциальная угроза проекту. Фактически это нереализованные ожидания. И основная цель работы с подателями такого рода требований — трансформация негатива в позитив. То есть превращение требований, противоречащих канве проекта, в требования, которые этой канве соответствуют. Вообще говоря, задача это далеко не самая простая — и во многом ее решение зависит от того, насколько человек, работающий «со стороны внедрения» обладает талантом убеждать и говорить просто о сложном. Третья категория — это требования, которые «выбиваются вверх». Они вроде бы и коррелируют с основным вектором развития системы, но при этом представляют собой трудно реализуемые вещи или же вещи, которые выполнить невозможно. Но в итоге с ними тоже следует работать — и работать на будущее. Во-первых, они могут составлять костяк следующего этапа развития системы; во-вторых — послужить основой для диалога, в котором частично могут быть перенесены в плоскость тех, что реализуемы.
Следующее, что надо сделать, — проговорить классифицированные требования с их авторами. Подобное общение обычно дает бесценный опыт, позволяя выявлять ожидания, стоящие за требованиями. Таким образом удается понять проблемы конкретных потребителей — то, для чего нужна данная работа. Отмечу, что наиболее плохая ситуация, когда пользователям приходится объяснять, что собственно, будет представлять собой решение на их участке работы. А это в итоге может привести к тому, что ожидания не оправдаются, и окончательное решение в лучшем случае будет принято холодно, а в худшем — полностью игнорироваться. А оно, как говорится, нам надо?
Вообще, говоря об ожиданиях, следует отметить, что они могут и должны меняться с течением времени, то есть перед началом проекта, на этапе сбора требований они одни. А после запуска — другие. Такая трансформация обычно связана с тем, что «аппетит приходит во время еды» и по мере знакомства с возможностями системы будущие пользователи и прочие заинтересованные лица станут ждать от нее все больше и больше. Этим процессом тоже важно управлять: стоит показать, что «золотой ключик», конечно, «будет наш», но в объеме изначальных договоренностей. Или, если реализация конкретного ожидания стоит исчезающе мало — принять решение о реализации. В конце концов, завоевать таким образом союзника важнее, чем настоять на своем.
А что скажет CIO?
Говоря сухим газетным языком, все изложенное выше — это «вести с полей». То есть взгляд, скажем так, линейного руководителя. А, как известно, чем выше в небо, тем темнее космос. Посмотрим на то же самое с точки зрения CIO.
Начнем с того, что любой проект со стороны CIO оценивается немного не так, как для руководителя проекта. Если в случае с РП действует правило «сделал, запустил, сдал — профит», то в случае с CIO «сделал, запустил, сдал» могут совершенно не означать тот самый профит. Связано это в первую очередь с тем, что CIO работает на более высоком уровне иерархии — в основном в области ожиданий и их реализации. Вообще, топ-менеджеры работают почти всегда на высоком уровне абстракции. Исключение составляют разве что CIO, поскольку приходится вникать в детали происходящего — так как иначе есть достаточно высокий шанс упустить что-то важное. Но еще раз подчеркну: CIO по отношению к остальному бизнесу точно так же работает на высоком уровне абстракции. А это автоматически подразумевает высокий уровень абстракции требований и ожиданий со стороны бизнеса буквально ко всем аспектам деятельности ИТ. Поэтому, говоря о CIO и его роли в управлении ожиданиями, можно сказать, что, во-первых, он работает с ожиданиями высокого уровня, а во-вторых, он сам выступает в роли того, кто формирует эти ожидания. И если с первым тезисом все более-менее понятно, то на втором стоит остановиться подробнее. Как выглядит типовое «послание» бизнеса ИТ? Да примерно так: «Печать должна работать бесперебойно», «Данные в системе должны быть защищены от краж» и т. д. ИТ должно обеспечить. Причем под обеспечением в таком контексте подразумевается прежде всего как выбор реализации, так и сама реализация. Вкупе с эксплуатацией. И уже задача CIO — найти решение, выработать план реализации, защитить его... По большому счету, все эти волнующие эпизоды с точки зрения бизнеса укладываются в емкое определение — «процесс». Бизнесу важен результат в поставленные сроки и за определенные деньги. Все остальное — от лукавого. Таким образом, CIO, работая с ожиданиями, зажат, с одной стороны, в классический «треугольник ограничений» проекта (ресурсы — сроки — качество), а с другой — над этим треугольником всегда будет стоять человеческий фактор. Насколько предложение CIO соответствует представлению бизнеса об идеальном решении? Ответ на этот вопрос лежит уже в области человеческих отношений CIO и представителей бизнеса — того невербального «моста», который смог выстроить CIO. Это, наверное, самый тонкий момент во всей связке ожиданий и бизнеса. И все сказанное еще обостряется, когда в «игру» вступают третьи лица — поставщики сервисов, внешние подрядчики, внутренний отдел ИТ. CIO в этом случае вынужден быть «един в двух лицах»: он поставщик сервиса и отвечает перед основным бизнесом за предоставленные решения и в то же время выступает в роли заказчика. При этом формируя ожидания как бизнеса, так и подрядчиков.
Постепенно CIO набирается опыта и вольно или невольно практически любой разговор сводит к ожиданиям. Это очень заметно по таким фразам: «А какую задачу вы решаете?», «Давайте определимся, что является наиболее приоритетным в данном контексте» и т. д. Даже более того, CIO становится зависим от ожиданий.
Давайте на секунду отвлечемся и подумаем, а как бизнес может оценить CIO? По каким критериям? Понятно, что у него почти наверняка есть какие-либо формальные KPI и он их с большой вероятностью выполняет. Но вот возникает ли у бизнеса удовлетворенность его работой и выполнением ожиданий — это вопрос. Ответ, на который как раз коррелирует с ответом на предыдущий вопрос. Проще говоря, CIO оценивают по тому, насколько он оправдывает ожидания...
«Стоп-стоп-стоп, — могут сказать мне. — CIO, конечно, оценивают по ожиданиям, но, чтобы оценка была объективной, есть KPI, и совсем они не бесполезны». С этим утверждением, в общем-то, поспорить трудно. Правда, истина состоит в том, что вне зависимости от KPI — CIO все равно будут оценивать по тому, насколько его результат соответствует внутренним ожиданиям бизнес-заказчика. Идеальный вариант — чтобы внутренние ожидания заказчика от деятельности CIO нашли бы отражение в KPI. В этом случае получаемая с их помощью картина станет достаточно объективной по внутренним и внешним признакам.
И что в итоге?
Самое сложное в подобных рассуждениях — подвести черту. В данном случае, получается, что ожидания как класс — это то, что вроде как «в лоб» не формализуемо. И работа с ожиданиями на всех уровнях зависит от мастерства того, кто непосредственно ими управляет — создает, реализует или опровергает. Причем ожидания такая вещь, которая, с одной стороны, очень проста и понятна (вот они, ждем что «все будет»), а с другой — «темный лес», в котором могут происходить самые невероятные вещи.
Тем не менее управление ожиданиями — вещь реальная, более чем реальная. И это доказывает, например, то, что есть множество CIO, находящихся в гармонии с бизнесом. И есть множество сотрудников, которые обеспечивают такую гармонию своим ежедневным трудом.
Опубликовано 01.07.2013