Записки странника из корпоративного лабиринта

Вступление

Знаете это чувство, когда заказчик просит «волшебную кнопку», технический директор смотрит на вас как на личного врага, а в договоре мелким шрифтом написано, что вы отвечаете за всё, включая падение сервера в новогоднюю ночь? Эта книга — не учебник. Это травелог. Сборник баек, мудрых советов и рецептов выживания от человека, который двадцать лет водил проекты через интеграционный ад, научился пить чай с драконами и остался жив.

Здесь нет скучных таблиц и графиков. Есть история о том, как с помощью пяти чашек чая приручить самого неприступного техдира. Есть трактат о природе пустых обещаний и магия «бумажного следа», спасающая в суде. Есть честный разговор о демоне выгорания — и простой рецепт, как не превратиться в унылое существо, ненавидящее утро понедельника.

Даже если вы в жизни не слышали слов «интеграционная шина» или «ГОСТ 34», вам будет интересно. Потому что эта книга — о людях. О том, как договариваться, когда договориться невозможно. О том, как сохранить себя в мире бесконечных дедлайнов. И о том, что однажды наступает вечер, когда можно выключить уведомления, заварить кружку чая с бергамотом и понять: проект сдан, команда жива, а ты — всё ещё ты.

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

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

● Полезная справка для тех, кто в танке: Кто такой этот ваш «руководитель проектов» и почему его работа — чистая магия, не признанная ни одним официальным министерством.

Глава 1

Обитатели Лабиринта: Краткий курс выживания среди аборигенов и их тотемов

(О природе интеграционных и сервисных проектов и о том, с кем вы будете иметь дело)

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

Первое, что стоит понять о мире, в который вы попали (или собираетесь попасть): здесь нет места иллюзии контроля. Есть только искусство навигации в условиях, когда компас врет, карта устарела, а половина экипажа говорит на незнакомом языке. Но именно это и делает нашу профессию достойной — не гарантированный результат, а сам процесс приручения хаоса.

Эта глава — о том, с чем мы вообще имеем дело и с кем нам предстоит делить дорогу. Без этого знания любой, даже самый гениальный план, рассыплется в пыль при первой же встрече с реальным заказчиком.

История первая: «Битва экстрасенсов в департаменте ИТ»

Представьте себе: вас вызывают в солидный офис. Большой стол, кожаные кресла, на стене — картина в золоченой раме. Напротив сидит уважаемый человек, директор по развитию, и говорит примерно следующее:

— Нам нужна система. Чтобы всё работало. Отчеты сами строились, данные не терялись, а сотрудники наконец перестали жаловаться, что у них ничего не открывается. Вы же можете сделать такую систему? Мы слышали, вы умеете.

И смотрит на вас с надеждой. Почти как ребенок, который верит, что в коробке с надписью «Волшебная кнопка» действительно лежит Волшебная Кнопка. А вы сидите и думаете: с чего бы начать разговор? С того, что «система» — это не одна программа, а целый зоопарк софта? С того, что «сами строились» — это не магия, а месяцы настройки и отладки? Или с того, что «не открывается» — это, скорее всего, криво настроенный браузер у бухгалтера, а не глобальная ИТ-проблема?

В этом и заключается главная сложность нашей профессии: мы работаем на стыке двух миров. В одном живут наши заказчики — люди, которым нужен результат, и желательно вчера. Они мыслят категориями «работает / не работает», «быстро / долго», «дорого / дешево». В другом мире обитаем мы — люди, которые понимают, что любое «работает» состоит из тысяч мелочей, каждая из которых может сломаться в самый неподходящий момент.

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

Строительство акведука и полив огорода

Есть два основных типа работы, которые в обиходе называют одним и тем же словом «проект». На самом деле разница между ними примерно такая же, как между строительством водопровода и ежедневным поливом грядок.

Первый тип — интеграционный проект. Это когда вы строите что-то уникальное, с четкой датой начала и, что еще важнее, с датой окончания. Вы пришли, сделали, сдали — и ушли (или перешли к следующей стройке). Примеры: внедрение системы электронного документооборота, миграция данных со старого сервера на новый, запуск интернет-магазина. У такого проекта есть три главных параметра: сроки, бюджет и объем работ. И есть одна главная цель — завершиться. Подписать акт, получить деньги и забыть этот кошмар хотя бы на пару недель.

Второй тип — сервисный контракт, или услуга. Это когда вы не строите, а поддерживаете. Вы продаете не результат «система внедрена», а состояние «система работает и доступна». Здесь нет финишной черты. Есть только следующий отчетный период — месяц или квартал. Вы как садовник, который обязался поливать огород каждый день, и неважно, идет дождь или светит солнце. Примеры: техническая поддержка, сопровождение серверов, аутсорсинг бухгалтерии.

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

На стройке вы мыслите этапами: фундамент, стены, крыша. Каждый этап заканчивается подписанием акта. Вы можете рассчитать, сколько осталось до конца, и видите свет в конце тоннеля. Ваш главный враг на стройке — изменение требований. Когда заказчик говорит: «А давайте еще бассейн сделаем!» — в тот момент, когда вы уже заливаете фундамент под гараж. Это меняет всё: сроки, бюджет, саму конструкцию.

В саду всё иначе. Вы просыпаетесь каждый день и делаете примерно одно и то же: поливаете, пропалываете, удобряете. Заказчик платит вам не за то, что «сад вырос», а за то, что «сад зеленый». Ваш главный враг здесь — недовольство. Когда пользователи говорят: «У нас опять ничего не открывается», а вы знаете, что проблема в том, что они забыли пароль, но признаться в этом не могут, потому что тогда придется признать свою ошибку. И начинается: вы доказываете, что система работает, они доказывают, что нет. Время идет, нервы тратятся, репутация трещит по швам.

Как мы продаем одно, а делаем другое

Теперь самое интересное. В реальной жизни чистые типы почти не встречаются. Точнее, встречаются, но только в учебниках. В российской действительности всё устроено хитрее.

Представьте: заказчик приходит и говорит: «Мы не знаем, какие отчеты нам понадобятся через полгода. Рынок меняется, требования меняются. Давайте вы просто выделите нам команду разработчиков на год, и они будут делать то, что мы просим». С точки зрения сути — это сервис. Он покупает ваше время и экспертизу. Но юристы обеих компаний смотрят на это и приходят в ужас. «Как это — мы не знаем, что вы будете делать? А вдруг вы будете год чай пить за наши деньги? Нет, давайте подпишем договор с этапами, сроками и конкретными результатами».

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

Обратная ситуация случается не реже. Вы берете на сопровождение «зоопарк» систем — десяток разных программ, написанных разными людьми в разное время на разных языках. По сути, это чистая поддержка. Но финансисты заказчика не могут провести платеж с пометкой «просто чтобы всё работало». Им нужен проект. И вот рождается чудесный документ под названием «Проект перехода на единую систему поддержки», в котором расписаны фазы, вехи и критерии успеха. Вы их честно выполняете, сдаете — и только после этого начинается настоящая работа, та самая, ради которой всё затевалось. И горе тому руководителю, который не заложил в этот «проект» время и деньги на неизбежный хаос первых месяцев реальной поддержки.

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

Бестиарий проекта: краткий справочник по местным жителям

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

Господин Финансовый Директор (существо доброе, но пугливое)

Это человек, который выделяет деньги. Он не понимает разницы между языками программирования, не знает, что такое API, и искренне считает, что «сервер» — это такой большой компьютер, который гудит. Но именно он подписывает бюджет. Именно его боится бухгалтерия. И именно он будет тем человеком, который скажет: «Мы заплатили миллионы, а где результат?».

С ним нужно работать бережно. Он не враг, он союзник, просто очень пугливый. Его главный страх — выглядеть глупо перед генеральным директором или акционерами. Если проект идет не по плану, он никогда не скажет: «Я ошибся, когда утверждал эту концепцию». Он скажет: «Подрядчик не справился». Ваша задача — никогда не ставить его в ситуацию, где ему придется оправдываться.

Как этого добиться? Давать ему простые, понятные статусы. Не «рефакторинг модуля обработки транзакций завершен на 70%», а «система сможет формировать месячный отчет за час, а не за ночь, как раньше». Он должен видеть связь между потраченными деньгами и конкретной пользой для бизнеса. И еще: всегда предупреждайте его о проблемах заранее. Если он узнает о срыве сроков от своего начальника, а не от вас, — вы проиграли.

Главный Безопасник (страж порога с тремя головами)

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

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

У него три головы, как у сказочного дракона. Первая голова — Федеральная служба по техническому и экспортному контролю (ФСТЭК), которая требует сертификации всего и вся. Вторая голова — закон о персональных данных (152-ФЗ), который запрещает хранить сведения о людях где попало и как попало. Третья голова — внутренние регламенты компании, которые часто противоречат первым двум головам, но считаются «политикой партии» и обсуждению не подлежат.

Как с ним быть? Есть только один работающий метод: включите его в рабочую группу с самого начала. Дайте ему возможность проверить архитектуру на бумаге, до того, как вы написали первую строку кода. Пусть он выскажет все свои опасения на этапе проектирования, а не на этапе сдачи. И обязательно закладывайте на его «реакцию» не меньше трех недель в любом плане. Если он ответил быстрее — считайте это подарком судьбы.

Технический Директор (дракон, охраняющий залежи старого кода)

Это самый сложный персонаж в нашем бестиарии. Как правило, это человек, который проработал в компании десять-пятнадцать лет. Он знает все системы вдоль и поперек. Он помнит, кто, когда и зачем поставил тот самый патч, без которого всё падает. Он — ходячая энциклопедия, и он прекрасно об этом знает.

И тут приходите вы. Со своим новым софтом, своими «правильными» методологиями и своей командой. Вы говорите: «Мы всё переделаем, будет лучше». А он слышит: «То, что вы делали последние десять лет, — ерунда, сейчас мы вам покажем, как надо».

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

Как с ним работать? Война здесь — путь в никуда. Победить дракона в открытом бою нельзя, особенно на его территории. Но можно его приручить. Для этого есть специальная техника, которую я называю «Пять чашек чая». Мы подробно разберем ее в пятой главе, а пока запомните главное: этот человек должен стать вашим союзником. Не врагом, не оппонентом, не «терпилой», который вынужден с вами работать. Союзником. И это возможно, хотя и требует немалого терпения и некоторой гибкости.

Бухгалтер Мария Ивановна (хранительница вселенной)

И, наконец, самый недооцененный персонаж. Конечный пользователь. Тот самый человек, который будет работать в вашей системе каждый день. В нашем примере это Мария Ивановна, бухгалтер с двадцатипятилетним стажем. Она знает пятьдесят горячих клавиш наизусть. Она может ввести проводку быстрее, чем вы наливаете чай. Она — душа компании, хотя сама об этом не подозревает.

И вот вы приносите ей новую систему. Интерфейс другой, кнопки не на тех местах, привычные комбинации не работают. Вы говорите: «Это современнее и удобнее». А она слышит: «То, что вы делали двадцать пять лет, — неправильно, учитесь заново». И начинается тихий саботаж. Она не будет ругаться, не будет писать жалоб. Она просто будет работать в старой системе, пока это возможно, а новую — открывать раз в день, чтобы отметиться. А потом ее подруги из других отделов тоже начнут вздыхать: «Ох, эта новая система, опять ничего не понятно, вот раньше-то было...».

Игнорировать таких людей — значит обречь проект на провал. Можно идеально выполнить все формальные требования, сдать систему по акту и получить деньги. Но если Мария Ивановна и ее коллеги не приняли систему — она умрет. Не сразу, постепенно. Ей перестанут пользоваться, потом найдут повод вернуться к старой, а вашу — тихо похоронят в каком-нибудь приказе о «нецелесообразности дальнейшей эксплуатации».

Как этого избежать? Подружитесь с Марией Ивановной. Сядьте рядом с ней, посмотрите, как она работает. Спросите, что ей нравится в старой системе, а что раздражает. Дайте ей почувствовать себя не объектом внедрения, а соавтором. Иногда достаточно одной персональной консультации и маленькой «шпаргалки» с новыми горячими клавишами, чтобы самый ярый противник стал вашим союзником.

История вторая: «Новогоднее чудо и акт сдачи-приемки»

Теперь, когда мы познакомились с основными обитателями нашего лабиринта, позвольте рассказать историю, которая многое объясняет про то, как устроен этот мир.

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

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

И вот начинается волшебство. За две недели до Нового года люди, которые месяцами не могли согласовать простейший макет интерфейса, вдруг обретают невиданную расторопность. Технический директор, который воевал с нами всё лето, внезапно соглашается на все наши условия. Главный безопасник подписывает заключение, даже не читая (потом, конечно, аукнется, но это потом). А господин финансовый директор лично звонит мне и спрашивает: «Может, вам машину прислать, чтобы акты привезли побыстрее?».

В чем дело? Неужели люди исправились? Прониклись духом Рождества? Нет. Просто у них есть годовой бюджет. Деньги, которые не потрачены до 31 декабря, — сгорают. И остаться без бюджета на следующий год для них страшнее, чем принять систему с мелкими недоделками. Страшнее, чем подписать акт с Протоколом разногласий на десять страниц. Страшнее, чем потом три месяца доделывать то, что не успели.

Это чисто российская специфика, и не пользоваться ею было бы глупо. Но тут есть и обратная сторона: если вы планируете сдачу на середину января — готовьтесь к тому, что все будут заняты, всем будет некогда, и процесс, который в декабре занял бы неделю, растянется на два месяца. Просто потому, что бюджет уже принят, деньги уже не горят, и можно снова начинать бодаться за каждую запятую в документации.

Из этой истории следует важный урок: календарь — это не просто сетка с датами. Это карта приливов и отливов. Есть месяцы, когда проекты подписываются и сдаются с космической скоростью (конец июня и конец декабря). Есть месяцы, когда все в отпусках (июль-август, вторая половина декабря, первая половина января). Есть месяцы, когда все готовятся к отпускам (май). Всё это нужно учитывать при планировании, иначе ваш идеальный график разобьется о реальность так же неизбежно, как волна разбивается о скалы.

Справка: Легенда о Великом ГОСТ 34

Раз уж мы заговорили о формальностях, давайте сразу проясним одну важную вещь. В мире российских ИТ-проектов есть документ, который обладает почти мистической силой. Он называется ГОСТ 34. Точнее, ГОСТ 34.601-89 — «Автоматизированные системы. Стадии создания». И еще несколько родственных ему стандартов из той же серии.

Этот документ был написан в 1989 году, когда компьютеры были большими, интернет — медленным, а слова «гибкая методология» никто не знал. Он подробно описывает, как должна создаваться автоматизированная система: какие стадии проходить, какие документы выпускать, как эти документы называть. Техническое задание, Эскизный проект, Технический проект, Рабочая документация — всё это оттуда.

Молодые руководители проектов часто морщатся при упоминании ГОСТа: «Это прошлый век, мы по-современному работаем, у нас Agile и спринты». Я тоже так думал. Пока не проиграл суд.

Понимаете, в чем дело: судье плевать на ваш спринт. Он смотрит в Гражданский кодекс, где написано, что подрядчик должен выполнить работы в соответствии с технической документацией, определяющей объем и содержание работ. А что такое «техническая документация»? А это то, что «обычно предъявляется». А что обычно предъявляется в РФ? Правильно, ГОСТ 34.

Поэтому мой вам совет: не воюйте с ГОСТом. Сделайте его своим союзником. Никто не требует от вас писать талмуд на пятьсот страниц. Но если в вашем договоре есть фраза «Техническое задание должно соответствовать требованиям ГОСТ 34.602-89», то в случае спора суд встанет на вашу сторону, если вы этот ГОСТ соблюли. А если вы написали ТЗ «в свободной форме» — суд будет гадать, что имелось в виду, и, скорее всего, додумает не в вашу пользу.

Это как правила дорожного движения. Можно считать их скучными и ограничивающими. Но когда вы едете по трассе и видите, что встречная машина тоже соблюдает правила, вы понимаете, зачем они нужны. ГОСТ 34 — это правила движения в мире корпоративных ИТ-проектов. Не пренебрегайте ими.

На этом первая глава заканчивается. Мы познакомились с местностью и местными жителями. В следующей главе мы поговорим о том, как обещать — и не попадать в ловушку собственных слов. Потому что, как выясняется, корень восьмидесяти процентов проблем лежит не в коде и не в серверах, а в тех самых первых бумагах, которые мы подписываем, даже не читая.

Глава 2

Искусство обещать, или Фундамент, вырытый в зыбучих песках

(Коммерческое предложение и Устав проекта: как не пообещать трон из чистого золота, если в наличии только табурет и три доски)

Есть такая старая шутка. Встречаются два приятеля. Один говорит: «Я тут решил дом построить. Уже и смету составил, и план нарисовал». Второй спрашивает: «А опыт у тебя есть?» — «Ну, я в детстве из кубиков замки строил». — «Отлично, тогда ты готов к встрече с прорабом, который из кубиков строил только пирамидки».

Примерно так выглядит встреча руководителя проекта с коммерческим предложением, которое написали его коллеги из отдела продаж. Вы открываете документ, читаете: «Мы разработаем и внедрим систему полной автоматизации бизнес-процессов за три месяца» — и понимаете, что три месяца назад кто-то очень обаятельный и очень далекий от реальности уже пообещал заказчику луну с неба. А вам теперь эту луну доставать.

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

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

Трактат о природе пустых обещаний

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

В разделе «Состав работ» я обнаружил фразу: «Миграция всех исторических данных в новую систему». Звучит прекрасно. Но когда я приехал к заказчику и спросил: «А сколько у вас исторических данных?» — меня отвели в подвал. В прямом смысле. Там, в подвале, стояли ряды металлических шкафов, в которых хранились папки с документами за пятнадцать лет. Я насчитал примерно пятьдесят тысяч единиц. Пятьдесят тысяч документов, которые нужно было отсканировать, распознать, проиндексировать и загрузить в систему.

Я вернулся в офис и спросил у коллеги, который писал предложение: «Ты видел их архив?» Он ответил: «Нет, а что там?» — «Там пятьдесят тысяч документов». Он задумался на секунду и сказал: «Ну, мы же не обязаны это делать, в договоре этого нет». Я показал ему фразу «Миграция всех исторических данных». Он пожал плечами: «Ну, это же просто слова, чтобы красиво выглядело».

Вот так мы и живем. Продавцы пишут красивые слова, чтобы завлечь клиента. Заказчик читает эти слова и думает: «Отлично, они всё сделают, я могу расслабиться». А потом приходим мы, руководители проектов, и должны как-то разгребать этот завал из взаимных иллюзий.

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

Техника «Трех точек неопределенности», или Искусство гадать на кофейной гуще с пользой для дела

Теперь перейдем к практическим инструментам. Когда мы оцениваем, сколько времени займет та или иная работа, мы всегда находимся в ситуации неопределенности. Мы не знаем точно, с какими проблемами столкнемся, как быстро заказчик будет отвечать на наши вопросы, не упадет ли сервер в самый неподходящий момент. Но оценку давать надо — иначе мы не сможем назвать цену и сроки.

В классической теории управления проектами для этого используют метод PERT — Program Evaluation and Review Technique. Если совсем просто: мы берем три оценки — оптимистичную (всё идет идеально), пессимистичную (всё идет наперекосяк) и наиболее вероятную (где-то посередине). А потом считаем итоговую оценку по формуле: (Оптимистичная + 4 × Вероятная + Пессимистичная) / 6.

Это прекрасный метод. Он работает. Но в российских реалиях я внес в него небольшую поправку. Я заметил, что пессимистичный сценарий у нас случается заметно чаще, чем предсказывает классическая формула. Не потому, что мы пессимисты. Просто количество факторов, которые мы не контролируем, в нашей реальности выше.

Например: вы планируете интеграцию с системой бухгалтерского учета. Оптимистичный сценарий: у смежной системы есть документированный API, он работает как описано, вы подключаетесь за два дня. Вероятный сценарий: API есть, но документация устарела, приходится разбираться методом проб и ошибок, вы подключаетесь за неделю. Пессимистичный сценарий: выясняется, что API закрыт для внешних подключений по соображениям безопасности, нужно писать отдельный адаптер и согласовывать его с отделом информационной безопасности, вы подключаетесь за месяц.

А теперь представьте, что таких стыков у вас в проекте двадцать штук. Если вы по каждому дадите «честную среднюю» оценку, вы почти наверняка промахнетесь в меньшую сторону. Потому что из двадцати стыков хотя бы один-два пойдут по пессимистичному сценарию. А если пойдут три-четыре — вы вылетаете из сроков с треском.

Поэтому я использую модифицированную формулу, где пессимистичный сценарий имеет чуть больший вес. Итоговая оценка получается более консервативной, зато более реалистичной. Да, на тендере такая оценка может проиграть более «оптимистичной» от конкурентов. Но лучше честно назвать срок и уложиться в него, чем пообещать нереальное и прослыть обманщиком.

Пример из жизни

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

Оптимистичный сценарий: мы находим утилиту, которая конвертирует старый формат в новый, запускаем, проверяем — готово. Оценка: сорок часов.

Вероятный сценарий: утилита работает неидеально, часть данных теряется, приходится писать скрипты для ручной выверки и исправления ошибок. Оценка: сто двадцать часов.

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

По классической формуле: (40 + 4 × 120 + 300) / 6 ≈ 137 часов.

По моей формуле с повышенным весом пессимизма: (40 + 3 × 120 + 2 × 300) / 6 ≈ 167 часов.

Разница — тридцать часов, примерно неделя работы одного человека. Мы заложили сто семьдесят часов. Угадайте, что случилось на проекте? Правильно, пессимистичный сценарий. Конвертера не нашлось, формат оказался уникальным, пришлось писать всё с нуля. Мы уложились в триста часов, потому что были к этому готовы. А если бы заложили сто сорок — были бы в глубокой яме.

История третья: «Тайна приложения №1»

Теперь, когда мы разобрались с оценками, перейдем к самой важной бумаге в любом проекте. Нет, не к техническому заданию. К тому, что идет Приложением №1 к договору. Обычно оно называется «Состав и объем работ», или «Спецификация», или «Техническое задание» (не путать с полноценным ТЗ по ГОСТу, которое мы обсуждали в первой главе).

Этот документ — ваша конституция. Всё, что в него входит, вы обязаны сделать. Всё, что не входит — не обязаны. Звучит просто, правда? На практике именно здесь происходит самое интересное.

Вернемся к истории про подвал с документами. Когда я обнаружил те самые пятьдесят тысяч папок, я сделал единственно правильную вещь: сел и переписал Приложение №1.

В первоначальной версии там было написано: «Обеспечить хранение электронных копий всех документов компании». Я заменил это на: «Обеспечить хранение электронных копий документов, создаваемых в Системе с даты начала опытно-промышленной эксплуатации. Ретроспективный ввод (сканирование) архивных документов, созданных до даты начала ОПЭ, выполняется силами и за счет Заказчика либо оплачивается дополнительно».

Заказчик, когда увидел новую формулировку, сначала нахмурился. «Но вы же обещали...» — начал он. Я ответил: «Мы обещали, что система будет хранить документы. Она будет. Но кто будет загружать в нее старые документы — это отдельный разговор. У вас есть люди, которые могут это сделать?» Выяснилось, что людей нет. «Тогда мы можем сделать это сами, — сказал я, — но это дополнительная работа, и она стоит денег».

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

Правило «Явного исключения»

Из этой истории вытекает правило, которое я называю «правилом явного исключения». Когда вы пишете Приложение №1, недостаточно сказать, что входит в проект. Нужно обязательно сказать, что НЕ входит. И сказать это максимально конкретно.

Плохая формулировка: «Автоматизация процесса продаж». Хорошая формулировка: «Автоматизация процесса прямых продаж департаменту корпоративных клиентов, за исключением розничных продаж и продаж через партнерскую сеть».

Плохая: «Разработка личного кабинета пользователя». Хорошая: «Разработка веб-версии личного кабинета пользователя для браузеров Chrome и Firefox. Разработка мобильного приложения в данный объем работ не входит и оплачивается отдельно».

Плохая: «Интеграция с системой бухгалтерского учета». Хорошая: «Разработка модуля интеграции с системой "1С:Бухгалтерия" версии не ниже 3.0 по протоколу REST API. В объем работ входит настройка передачи данных о счетах и платежах. Интеграция с другими системами бухгалтерского учета, а также передача данных о заработной плате в данный объем не входят».

Каждое такое уточнение может показаться мелочью на старте. Но поверьте моему опыту: именно эти мелочи спасают проекты. Потому что на этапе приемки заказчик обязательно вспомнит, что «мы же договаривались про мобильное приложение». И вы откроете Приложение №1, покажете строчку «не входит» — и разговор перейдет из плоскости «вы не сделали» в плоскость «давайте обсудим, сколько это стоит и когда мы это сделаем». Это совершенно другой разговор.

Устав проекта: ваш личный мандат

Теперь поговорим о документе, которого в договоре обычно нет, но который я настоятельно рекомендую составить для внутреннего пользования. Это Устав проекта. В классической методологии PMI это документ, который формально авторизует проект и наделяет руководителя полномочиями. В нашей реальности это скорее ваш личный компас, который не даст сбиться с пути.

Что должно быть в Уставе? Не так много, как кажется.

Первое: цели проекта, сформулированные на языке бизнеса. Не «внедрить CRM», а «сократить время обработки заявки клиента с двух дней до четырех часов». Это важно, потому что в середине проекта, когда начнется хаос из изменений и доработок, вы всегда сможете задать вопрос: «То, что вы сейчас просите, приближает нас к цели или отдаляет?». И если ответ «не приближает» — это повод перевести разговор в коммерческое русло.

Второе: границы проекта. То, о чем мы только что говорили. Что входит, а что — категорически нет.

Третье: ключевые допущения. Это волшебный раздел, который спас меня больше раз, чем я могу сосчитать. Суть его в том, что мы честно пишем: «Мы исходим из того, что смежная система предоставляет API версии не ниже такой-то. Если версия окажется ниже — это изменение объема работ». Или: «Мы исходим из того, что серверное оборудование будет предоставлено Заказчиком в течение десяти рабочих дней с даты подписания настоящего документа». Если сервер не предоставили — сроки сдвигаются, и это не наша вина.

Четвертое: список заинтересованных лиц с их ролями. Не «Заказчик» вообще, а конкретно: Иванов И.И., финансовый директор — спонсор проекта, Петров П.П., технический директор — согласование архитектуры, Сидорова М.И., главный бухгалтер — согласование отчетных форм. Когда у вас есть такой список, вы всегда знаете, к кому идти за каким решением.

И пятое, самое важное: критерии успеха. Что должно произойти, чтобы проект считался успешным? Обычно это: система работает согласно ЧТЗ, акты подписаны, деньги получены. Но я всегда добавляю еще один критерий: «Отсутствие судебных разбирательств и репутационных потерь». Потому что можно получить деньги и разругаться так, что десять лет тебя будут вспоминать с содроганием. А можно — получить деньги и сохранить отношения для будущих проектов. Это два разных «успеха».

Трактат о границах, или Заклинание «Нет», которое звучит как «Да»

Теперь позвольте мне поделиться одним наблюдением. Многие начинающие руководители проектов боятся слова «нет». Им кажется, что если они откажут заказчику в какой-то просьбе, это испортит отношения, и проект пойдет насмарку. Это опасное заблуждение.

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

Но есть искусство в том, как именно говорить это «нет». Никогда не говорите: «Нет, мы этого делать не будем, это не входит в договор». Это звучит как отписка. Говорите иначе: «Да, это отличная идея. Мы можем это сделать. Давайте обсудим, как это повлияет на сроки и бюджет, и зафиксируем дополнительным соглашением». Вы не отказываете. Вы переводите вопрос из плоскости «должен / не должен» в плоскость «когда и за сколько». Это совершенно другой разговор.

У меня был случай, когда заказчик в середине проекта попросил добавить отдельный модуль для работы с филиалами. По первоначальному плану система охватывала только головной офис. Я не сказал «нет». Я сказал: «Это серьезное расширение функционала. Давайте я оценю трудозатраты, мы подготовим предложение по срокам и стоимости, и вы примете решение». Через неделю я принес расчеты. Заказчик посмотрел на цифры, подумал и сказал: «А давайте пока без филиалов, но с перспективой подключения в следующем году». В итоге мы сдали проект без филиалов, а через год — получили новый контракт на их подключение. Если бы я на старте просто сказал «нет, не входит» — второго контракта, скорее всего, не было бы.

Справка: Что важно помнить об этапе инициации

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

Первое: нет ничего опаснее фразы «мы это потом уточним». Всё, что вы не уточнили до подписания договора, превратится в повод для спора после. Уточняйте на берегу. Пусть это займет лишнюю неделю или две. Это сэкономит месяцы потом.

Второе: всегда читайте коммерческое предложение. И если находите там «красивые слова» — требуйте их расшифровки в Приложении №1. Что именно значит «полная автоматизация»? Что именно значит «бесшовная интеграция»? Что именно значит «интуитивно понятный интерфейс»? Каждое прилагательное должно быть превращено в измеримый критерий.

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

Четвертое: учитесь говорить «нет» через «да». Это навык, который отличает зрелого руководителя от начинающего. Не бойтесь обсуждать деньги и сроки. Это ваша работа.

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

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

Глава 3

Управление Желаниями, или Как объяснить заказчику, чего он хочет на самом деле

(Сбор требований и защита от бесконечного «А вот еще эту кнопочку...»)

Где-то на третьем году моей карьеры я сделал открытие, которое перевернуло мое представление о профессии. Я сидел на встрече с заказчиком, который в двадцатый раз объяснял, какой именно отчет ему нужен, и вдруг понял: он не врет. Он не притворяется. Он действительно не знает, чего хочет. Но при этом абсолютно уверен, что знает.

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

В мире ИТ-проектов происходит ровно то же самое. Заказчик приходит к нам с готовым решением: «Сделайте мне вот такую кнопку, которая формирует отчет мгновенно». И если мы просто берем и делаем эту кнопку — мы поступаем как плохой врач, который выписывает рецепт не глядя. Возможно, кнопка действительно нужна. А возможно, проблема совсем в другом, и наша кнопка ее не решит, а только добавит новых проблем.

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

Дзен и искусство уборки в чужой голове

Есть такой метод — «Пять Почему». Его придумали японцы для анализа производственных проблем, но он прекрасно работает и в нашем деле. Суть проста: когда вы слышите требование, вы задаете вопрос «почему?». Получив ответ — снова спрашиваете «почему?». И так пять раз, пока не докопаетесь до настоящей причины.

Звучит просто. На практике — требует некоторой деликатности, потому что пятое «почему» может изрядно разозлить собеседника, если задавать его без должного такта.

Позвольте привести пример из жизни. На одном проекте заказчик — назовем его господин Финансовый Директор — потребовал, чтобы отчет о дебиторской задолженности формировался не за час, как сейчас, а мгновенно. «Нажимаю кнопку — и сразу вижу результат», — сказал он. Технически это означало переделку всего хранилища данных, закупку нового оборудования и полгода работы. Бюджет проекта вырастал вдвое.

Я попросил разрешения задать несколько вопросов. Разговор шел примерно так:

— Почему отчет должен формироваться мгновенно? — Потому что бухгалтер тратит слишком много времени на ожидание.

— Почему это проблема? Что не успевает бухгалтер? — Она сдает сводку мне каждый день в десять утра. Если отчет формируется час, она должна начинать в девять. А в девять у нее еще куча других дел.

— Почему сводка нужна именно в десять? — Потому что в десять тридцать у меня встреча с генеральным, и я должен быть готов ответить на вопросы о просроченной задолженности.

— Почему вы не можете ответить на вопросы без сводки? — Ну... я могу, но боюсь ошибиться. Генеральный спрашивает очень конкретно: кто из клиентов просрочил больше чем на неделю и на какие суммы. Я не держу эти цифры в голове.

— А если бы система сама подсвечивала проблемных клиентов и отправляла вам уведомление вечером накануне? Чтобы вы с утра уже знали картину, не дожидаясь отчета?

Пауза. Он задумался.

— Знаете, это было бы даже удобнее.

Вместо перестройки всей системы мы сделали небольшой модуль оповещений, который работал по ночам и присылал руководителю краткую сводку на почту. Времени на разработку — три недели вместо полугода. Денег — в десять раз меньше. Проблема решена. Заказчик счастлив.

В этом и заключается суть метода. Мы не спорим с требованием. Мы не говорим: «Вы не правы, ваша кнопка не нужна». Мы задаем вопросы, которые помогают человеку самому докопаться до сути. И часто оказывается, что за громким «мне нужно мгновенно» стоит тихое «я боюсь выглядеть некомпетентным перед начальством». А эта проблема решается совсем другими средствами.

Как слушать не ушами, а блокнотом

Есть еще одна техника, которую я настоятельно рекомендую освоить. Называется «наблюдение на территории». Суть ее в том, что вы не вызываете пользователя в переговорную для интервью, а идете к нему сами. Садитесь рядом и смотрите, как он работает.

Почему это важно? Потому что между тем, что человек говорит о своей работе, и тем, что он реально делает, — пропасть. Он может не помнить половину операций, которые совершает на автомате. Он может считать какую-то процедуру «само собой разумеющейся» и даже не упомянуть о ней. Он может стесняться признаться, что пользуется какими-то обходными путями, потому что «так неправильно, но работает».

Я помню случай, когда мы внедряли систему в бухгалтерии. По всем опросам выходило, что работа идет строго по регламенту: открыли документ, проверили, провели, закрыли. Но когда я сел рядом с бухгалтером на полдня, то увидел удивительную вещь. Перед каждым проведением сложного документа она открывала Excel, вбивала туда несколько цифр, сверяла с каким-то своим внутренним реестром — и только потом нажимала кнопку «Провести». Этот Excel-файл передавался от одного бухгалтера к другому уже лет пять. Он был их главным контрольным инструментом, их страховкой от ошибок. Но в интервью никто про него не вспомнил — не потому что скрывали, а потому что считали это «неважным».

Если бы мы не увидели этот файл своими глазами, мы бы построили систему, в которой бухгалтерам пришлось бы работать без привычной «страховки». Они бы нервничали, ошибались, саботировали. А так мы просто встроили аналогичную проверку в саму систему, и переход прошел гладко.

Отсюда правило: никогда не ограничивайтесь разговорами в переговорной. Идите туда, где работают люди. Смотрите на их мониторы. Задавайте вопросы: «А это что за файл? А почему вы сейчас нажали именно сюда? А что будет, если эту галочку не ставить?». Вы узнаете о проекте больше за один день наблюдений, чем за неделю формальных интервью.

История четвертая: «Карта сокровищ»

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

Дело было на проекте внедрения системы электронного документооборота. Мы должны были автоматизировать процесс согласования договоров — от создания заявки до отправки в банк. Заказчик прислал нам тридцать страниц требований, написанных в стиле «система должна обеспечивать», «система должна позволять», «система должна предусматривать». Честно говоря, после второго прочтения я уже не понимал, что за чем идет и кто кому что передает.

Тогда мы собрали всех ключевых участников процесса в одной комнате. Юрист, финансовый директор, бухгалтер, секретарь, который регистрирует договоры, и даже курьер, который их развозит. Мы взяли большую стену, заклеили ее бумагой и нарисовали горизонтальную линию. Над линией — шаги процесса: «Создание заявки», «Проверка юристом», «Утверждение финансами», «Регистрация», «Отправка в банк». Под каждым шагом мы начали клеить цветные стикеры с конкретными действиями. Желтые — что делает пользователь. Синие — что делает система. Красные — что идет не так и требует обработки ошибок.

Первые два часа все спорили. Юрист утверждал, что договор сначала проверяет он, а потом финансы. Финансовый директор — что наоборот. Оказалось, они оба правы: есть два типа договоров, для каждого свой порядок. На словах это было неочевидно, но на стене стало видно сразу.

Потом мы наткнулись на странный момент. На этапе «Отправка в банк» висело три стикера, но никто не мог объяснить, как именно данные из системы документооборота попадают в банковскую систему. Пригласили айтишника. Выяснилось, что никак. Данные выгружаются в Excel, потом бухгалтер вручную вбивает их в банк-клиент. Это занимало два часа каждый день. И это был ровно тот процесс, который мы должны были автоматизировать, но про который забыли спросить.

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

Формализация без фанатизма, или Как подружить бумажного голема и живую гибкость

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

В первой главе я уже упоминал ГОСТ 34 — наш отечественный стандарт на создание автоматизированных систем. Так вот, этот ГОСТ предполагает, что у проекта должно быть Техническое Задание. И многие руководители проектов впадают в одну из двух крайностей.

Одни пишут ТЗ на триста страниц, с детальным описанием каждого поля ввода, каждого сообщения об ошибке, каждого алгоритма. Они тратят на это полгода. Когда ТЗ готово, оно уже устарело, потому что за полгода изменились и бизнес-процессы, и технологии, и само понимание задачи. Это бумажный голем — огромный, неповоротливый, никому не нужный.

Другие говорят: «ГОСТ — прошлый век, мы работаем по гибкой методологии, у нас вместо ТЗ — бэклог, который мы уточняем каждые две недели». Это прекрасно работает, пока проект не попадает в суд. В суде гибкий бэклог — ничто. Судья хочет видеть бумагу с печатью.

Истина, как всегда, посередине. Я называю это «облегченным ЧТЗ» — документом, который закрывает юридические риски, но не пытается описать систему с точностью до пикселя.

Что должно быть в таком ЧТЗ обязательно?

Первое: общие сведения. Наименование системы, сроки, перечень документов, на основании которых она создается. Важный момент: в этот перечень стоит включить не только договор, но и протоколы ключевых встреч, где принимались важные решения. Это легитимизирует вашу деловую переписку. Если в протоколе написано, что стороны договорились о формате обмена данными, — это становится частью контрактных обязательств.

Второе: требования к функциям. Здесь мы не расписываем каждый чих, а описываем крупные блоки. «Система должна обеспечивать автоматическое формирование счета-фактуры при проведении документа "Реализация товаров и услуг"». Этого достаточно. Как именно система будет это делать — вопрос архитектуры, а не ТЗ.

Третье: требования к интеграции. Самый важный для нас раздел. Протоколы, форматы, таймауты, частота обмена. «Интеграция с банковским модулем осуществляется через REST API по протоколу HTTPS. Формат сообщений — JSON в соответствии со схемой, приведенной в Приложении 3». И обязательно: «Смежная система должна обеспечивать API версии не ниже 2.1». Это защита от ситуации, когда заказчик дает вам устаревшую версию, а вы должны с ней работать.

Четвертое: порядок приемки. Какие испытания проводятся, на каком стенде, кто подписывает протоколы. Это скучно, но это спасет вас в финале.

Всё остальное — в бэклог, в рабочие документы, в протоколы встреч. Они живые, они меняются, но они не имеют юридического веса. А ЧТЗ имеет. И этого достаточно.

Трактат о жадности и щедрости

Напоследок — о том, что случается неизбежно на любом проекте. Об изменениях. О том самом моменте, когда заказчик приходит и говорит: «А давайте еще вот эту кнопочку...».

Изменения — это нормально. Более того, это хорошо. Если в проекте нет изменений, значит, никто не пользуется его результатами. Изменения означают, что система живет, что люди начинают понимать, чего им на самом деле не хватает. Проблема не в изменениях. Проблема в том, что мы не умеем с ними работать.

У меня есть простой алгоритм обработки любого запроса на изменение. Он состоит из трех шагов.

Шаг первый: классификация. Что это вообще такое? Есть три варианта. Первый: дефект. Мы сделали не так, как написано в ТЗ. Это наша вина, мы исправляем бесплатно и сразу. Второй: уточнение. В ТЗ написано «отчет», но не указано, в каком формате. Теперь заказчик просит конкретный формат. Если это мелочь — делаем, фиксируем как «жест доброй воли» и идем дальше. Если крупно — обсуждаем. Третий: новое требование. Этого в ТЗ не было, это новая идея. Здесь мы достаем калькулятор и считаем деньги.

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

Шаг третий: техника «Управляемого Да». Никогда не говорите «нет». Говорите: «Да, это можно сделать. Вот три варианта. Первый: делаем сейчас, стоит столько-то, сроки сдвигаются на столько-то. Второй: делаем во втором релизе, будет дешевле и быстрее. Третий: делаем упрощенную версию сейчас, полную — позже». Заказчик чувствует, что им управляет он, а не вы. Он выбирает вариант, и это его решение, его ответственность. А вы — просто добросовестный исполнитель, который предупредил о последствиях.

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

Справка: Магия Матрицы Трассировки

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

Суть ее проста: это таблица, где в левом столбце перечислены все требования из ТЗ (каждое со своим номером), а в правых столбцах — ссылки на то, что это требование реализовано. Ссылка на пункт технического проекта, ссылка на тестовый сценарий, ссылка на акт проверки.

Когда на финальной приемке заказчик говорит: «А вот это у вас не работает!» — вы открываете матрицу и показываете: требование Р-045, «система должна отправлять уведомление инициатору», реализовано в модуле таком-то, проверено тестом таким-то, акт подписан такого-то числа. Всё работает. А то, о чем вы говорите, — это требование Р-046, которого нет в ТЗ, и мы готовы его реализовать за отдельную плату.

Матрица требует дисциплины. Ее нужно вести с самого начала проекта, актуализировать при каждом изменении, сверять с реальностью. Это скучная работа. Но однажды она спасет вас от многочасового спора, который ничем не закончится, кроме испорченных нервов. А иногда — и от судебного иска.

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

Глава 4

Гибридный подход, или Как пересечь море в лодке, которую достраиваешь на ходу

(Планирование в мире, где планы устаревают быстрее, чем ты произносишь слово «дедлайн»)

Когда я был совсем зеленым руководителем, у меня было одно незыблемое убеждение: хороший план — это половина успеха. Я проводил дни и ночи над диаграммами Ганта, выверяя зависимости, рассчитывая трудозатраты до десятых долей часа, раскрашивая задачи в разные цвета. Мои планы были произведениями искусства. Ими можно было любоваться. Их можно было вешать в рамочку.

Ровно до того момента, как они встречались с реальностью.

Обычно это происходило на второй-третьей неделе проекта. Внезапно выяснялось, что сервер, который нам обещали «завтра», будут закупать еще месяц. Или что ключевой сотрудник заказчика ушел в отпуск, не оставив заместителя. Или что смежная система, с которой мы должны интегрироваться, обновилась до новой версии, и наша документация больше недействительна. Мой прекрасный, выверенный план рассыпался, как карточный домик от сквозняка.

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

Эта глава — о том, как строить планы, которые выдерживают столкновение с реальностью. Не потому что они идеальны. А потому что они изначально предполагают, что реальность вмешается и всё испортит.

Невозможность чистого Agile

Давайте сразу расставим точки над одной модной буквой. В последние лет десять в мире информационных технологий царит настоящий культ гибких методологий. Agile, Scrum, Kanban — слова, которые произносят с придыханием, как названия священных текстов. Идея прекрасна: мы не пытаемся спланировать всё заранее, мы работаем короткими циклами, постоянно получаем обратную связь и адаптируемся.

Это работает. Честное слово, работает. Я сам использовал эти подходы много раз и буду использовать дальше. Но есть один нюанс, о котором забывают сказать на красивых презентациях.

Чистый Agile прекрасен, когда вы делаете продукт, который ни от кого не зависит. Когда вы — независимая команда, которая сама решает, что и когда выпускать. Когда у вас нет внешних обязательств перед регулятором, который требует сдать отчетность в строго определенном формате к строго определенной дате.

В мире интеграционных проектов такая роскошь встречается редко. Здесь вы почти всегда зависите от смежных систем. А смежные системы живут по своим законам. У них свои циклы разработки, свои сроки обновлений, свои ограничения. Вы можете хоть каждую неделю выпускать новую версию своего модуля — но если банковский шлюз обновляется раз в квартал, ваша гибкость упирается в их жесткость.

Кроме того, есть такое понятие, как регуляторные требования. Если вы внедряете систему, которая взаимодействует с государственными информационными системами, вы обязаны соблюдать определенные форматы, протоколы, регламенты. Они не меняются каждые две недели по вашему желанию. Они зафиксированы в приказах и постановлениях. И если вы их не соблюдаете — вы не «гибкий», вы — нарушитель.

И есть еще один момент, совсем прозаический. Договор. В российском корпоративном мире договор почти всегда заключается на фиксированный объем работ с фиксированными сроками. Заказчик платит не за процесс, а за результат. И он хочет понимать, когда этот результат будет достигнут. Если вы скажете ему: «Мы будем работать двухнедельными спринтами и когда-нибудь что-нибудь сдадим» — он, скорее всего, пойдет к вашим конкурентам.

Поэтому я использую подход, который называю «гибридным». Снаружи — жесткий каркас этапов и контрольных точек, который устраивает юристов, финансистов и регуляторов. Внутри — гибкое планирование, которое позволяет команде адаптироваться к изменениям, не ломая общий график.

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

История пятая: «Сага о кривом API»

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

Мы делали проект по интеграции системы управления взаимоотношениями с клиентами и учетной системы заказчика. По документации, которую нам предоставили на старте, учетная система имела REST API версии 2.0. Красивое, современное, документированное. Мы спланировали интеграцию на две недели: одна неделя на написание адаптера, одна — на тестирование. Всё четко, всё красиво.

Когда мы начали писать адаптер, выяснилось, что реальная версия API на тестовом стенде — не 2.0, а 1.7. Не та, что в документации. Мы спросили: «Почему?» Оказалось, что версия 2.0 еще в разработке, она «вот-вот будет», но пока — 1.7. В версии 1.7 не было половины нужных нам методов. Те, что были, работали не так, как описано. А документация на версию 1.7 была утеряна три года назад вместе с уволившимся разработчиком.

Наши две недели превратились в полтора месяца. Мы писали адаптер методом проб и ошибок: отправляли запрос, смотрели, что пришло в ответ, корректировали. Иногда ответ был XML вместо ожидаемого JSON. Иногда ответа не было вообще. Мы составили собственную документацию на API 1.7 — по сути, провели обратную разработку чужой системы.

Вот что я вынес из этой истории.

Первое: никогда не верьте документации на смежные системы, пока не пощупали их руками. Всегда закладывайте в план этап «технической разведки» — пару дней (а лучше неделю), когда ваши разработчики просто тыкают в API и смотрят, что оно отдает на самом деле.

Второе: любой стык со смежной системой — это риск. В плане он должен быть выделен отдельной строкой с отдельным буфером. Не «интеграция с системой А», а «интеграция с системой А (при условии предоставления доступа к тестовому стенду и актуальной документации)». Если доступ не предоставили или документация неактуальна — сроки автоматически сдвигаются, и это зафиксировано в плане.

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

Матрица ответственности с дополнительными буквами

Теперь поговорим о том, кто за что отвечает. В классическом управлении проектами для этого есть инструмент под названием RACI-матрица. R — Responsible, тот, кто делает. A — Accountable, тот, кто отвечает за результат. C — Consulted, тот, с кем советуются. I — Informed, тот, кого информируют.

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

Буква «П» — Предоставляющий. Это человек, который дает вам доступ к ресурсу, без которого работа невозможна. Например, системный администратор, выделяющий виртуальную машину. Или руководитель смежного подразделения, дающий разрешение на подключение к его системе. Если вы не зафиксировали в плане, кто именно и когда именно предоставляет ресурс, вы будете ждать вечность. А когда спросите «почему не сделано?», услышите: «А нам сервер не дали».

Буква «С-вето» — Согласующий с правом вето. Это человек, который не делает работу и не предоставляет ресурсы, но может сказать «нет». Обычно это представитель службы безопасности, главный бухгалтер или compliance-офицер. Их нужно включать в матрицу явно, потому что если вы про них забыли, они напомнят о себе в самый неподходящий момент — например, за день до сдачи системы.

Как это работает на практике? В плане, рядом с каждой задачей, у вас должны быть указаны не только исполнители, но и те, кто «предоставляет» и «согласует». Если на старте проекта эти ячейки пусты — план не готов. Это не бюрократия, это страховка.

Управление рисками как гадание на картах

Риски — это то, о чем все знают, но почти никто не работает с ними системно. Обычно реестр рисков ведется для галочки: открыли в начале проекта, записали десять стандартных фраз про «возможное изменение требований» и «недостаточную квалификацию персонала», закрыли и забыли. Это бессмысленно.

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

У меня есть своя колода таких карт. Вот некоторые из них.

Карта «Увольнение Спонсора». Это самый опасный риск в корпоративных проектах. Ваш главный сторонник, человек, который продавил бюджет и верит в ваш проект, внезапно покидает компанию. Новый руководитель приходит со своей командой, своими идеями, своими любимыми подрядчиками. Ваш проект для него — чужое наследство, от которого хочется избавиться.

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

Что делать? Формализовать всё. Превратить личные договоренности со спонсором в железобетонные бумаги: подписанные акты, утвержденные протоколы, оплаченные этапы. Если проект важен для бизнеса заказчика, новый руководитель не сможет его просто закрыть — ему придется принимать результат. А вы должны быть готовы заново «продать» проект, но уже не обещаниями, а демонстрацией работающей системы.

Карта «Импортозамещение в бою». Вы спроектировали систему на западном стеке. Проект идет полгода. Внезапно выходит постановление правительства, или служба безопасности заказчика выпускает директиву: перейти на отечественное программное обеспечение и оборудование. Ваш стек под запретом. Нужно всё переделывать.

Это не форс-мажор. Это реальность, к которой нужно быть готовым. В Уставе проекта должен быть пункт: «Технологический стек согласован сторонами в Приложении таком-то. Изменение стека по требованию Заказчика является существенным изменением условий и влечет пересмотр сроков и бюджета». Без этого пункта вы будете переписывать систему за свой счет.

Карта «Кривой API». Мы уже говорили об этом в истории про версию 1.7. Риск настолько частый, что я вынес его в отдельную карту. Всегда закладывайте время на проверку API до начала разработки. И всегда имейте в плане задачу с названием «Обследование смежных систем» — она окупается стократно.

Карта «Саботаж пользователей». Система работает, но люди отказываются в ней работать. Они пишут жалобы, находят ошибки, говорят «раньше было лучше». Это не техническая проблема, это социальная. И у нее есть решение: работа с неформальными лидерами. В каждом коллективе есть человек, к мнению которого прислушиваются. Найдите его. Сделайте его союзником. Потратьте на него вдвое больше времени, чем на остальных. Если он примет систему — примут и другие.

Реестр рисков нужно пересматривать регулярно. Каждую неделю, а в горячие периоды — каждый день. Что изменилось? Какие карты уже выпали? Какие могут выпасть завтра? Это не паранойя. Это профессиональная привычка.

Справка: Коэффициент «Внезапного регулятора» при расчете буферов

В конце этой главы позвольте дать простой практический совет про буферы. Буфер — это время, которое вы закладываете «на всякий случай». Не на конкретную задачу, а на непредвиденные обстоятельства.

В классической теории советуют закладывать буфер в размере пятнадцати-двадцати процентов от общей длительности проекта. Это работает в стабильном, предсказуемом мире. Мы живем не в таком.

За двадцать лет я выработал систему буферов, адаптированную под наши реалии.

Буфер на юристов и тендерный комитет: две-четыре недели. Любое дополнительное соглашение, любое изменение договора должно пройти через юридический отдел заказчика. Иногда — через тендерный комитет. Эти органы собираются по своему расписанию и живут в другом временном измерении. Если вам нужно срочно — у них «своего срока нет».

Буфер на безопасность: три-шесть недель. Проверка кода на уязвимости, аттестация стенда, получение заключений — это процессы, которыми вы не управляете. Вы отдаете документы и ждете. Иногда — долго.

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

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

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

В следующей главе мы поговорим о самом главном ресурсе — о людях. О том, как собрать команду, которая вытащит проект из любой ямы, и как разговаривать с теми, кто считает вас врагом. Это, пожалуй, самая важная глава в этой книге. Потому что технологии приходят и уходят, а люди остаются. И именно они делают проект успешным — или провальным.

Глава 5

Алхимия общения, или Как сварить суп из топора, техлида и пары джунов

(Психология и коммуникации: превращаем врагов в союзников, а тыкву — в карету)

Где-то на пятом году моей карьеры я поймал себя на странном ощущении. Я смотрел на свой проект, который только что с блеском провалился, и пытался понять, что пошло не так. Технически всё было сделано правильно. План был выверен до мелочей. Бюджет не превышен. Документация в порядке. А проект — мертв. Заказчик недоволен, команда деморализована, и даже акт сдачи-приемки, подписанный с грехом пополам, не приносил никакой радости.

Я сел и начал перебирать события последних месяцев, как перебирают старые фотографии. И вдруг увидел то, что всё это время было прямо перед глазами. Все критические точки, в которых проект сворачивал не туда, были связаны не с кодом, не со сроками, не с бюджетом. Они были связаны с разговорами. Точнее — с их отсутствием. Где-то я недоговорил. Где-то меня не услышали. Где-то я не услышал сам. Где-то нужные слова были сказаны, но не тому человеку и не в тот момент.

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

Эта глава — о людях. О тех, кто делает проект. И о тех, кто может его разрушить. О том, как собрать команду, способную на чудо. И о том, как разговаривать с теми, кто изначально настроен против вас.

Архетипы вашей команды: краткий справочник по разумным существам

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

В российском ИТ-бизнесе руководитель редко получает возможность набрать команду «с рынка» под новый проект. Чаще всего вам дают тех, кто «сейчас на скамейке запасных». Это значит, что вам достаются либо выгоревшие старожилы, либо неоперившиеся новички, либо проблемные сотрудники, от которых другие руководители уже избавились. Ваше искусство — собрать из этого разношерстного сброда боеспособный отряд.

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

Архитектор-Звезда, или Гений, требующий поклонения

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

Проблема в том, что вместе с гениальностью почти всегда идут специфические черты характера. Нетерпимость к «глупым вопросам». Нежелание объяснять очевидные (для него) вещи. Убежденность, что документация — удел слабаков, а его код сам себя документирует. И самое опасное — глубокая, почти мистическая вера в то, что проект держится исключительно на нем.

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

Как с ним работать? Есть несколько правил, проверенных горьким опытом.

Первое: признание и автономия. Никогда не пытайтесь контролировать его микроменеджментом. Скажите: «Вот функциональные требования. Архитектурные решения — твоя зона, я вмешиваюсь только если это влияет на сроки или бюджет». Ему нужно чувствовать, что вы ему доверяете. Что вы уважаете его экспертизу. Что вы не пытаетесь его учить.

Второе: парный ресурс. Приставьте к нему толкового разработчика уровнем пониже — не в помощь, а «на обучение». Скажите честно: «Ты гений, но проект не должен умереть, если ты заболеешь. Пусть коллега будет твоим дублером, твоя задача — сделать так, чтобы через месяц он понимал архитектуру не хуже тебя». Это решает сразу три задачи: страхует проект, развивает второго разработчика и, что немаловажно, тестирует адекватность самого Архитектора. Если он отказывается делиться знаниями — это тревожный звонок.

Третье: берегите его от рутины. Не заставляйте его ходить на совещания, где обсуждаются сроки и бюджеты. Не грузите его согласованием документов. Для этого есть вы. Его дело — писать код и думать. Всё остальное — ваша забота.

Сеньор-Скептик, или Ворчун, видящий грядущие беды

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

С ним сложно. Его скепсис заразен. Молодые разработчики слушают его и теряют мотивацию. Заказчик слышит его комментарии в кулуарах и начинает сомневаться в подрядчике. Но вот что важно понять: его скепсис — это оборотная сторона опыта. Он действительно видит риски лучше других. Просто он не умеет (или разучился) говорить о них конструктивно.

Однажды я нашел способ превратить его недостаток в достоинство. Я назначил такого скептика ответственным за качество. Сказал: «Ты видишь риски лучше всех. Твоя задача — найти всё, что может сломаться, до того, как это увидит заказчик. Ты — наш главный критик, но с одним условием: на каждую проблему ты предлагаешь хотя бы один вариант решения. Не "всё пропало", а "вот что может пойти не так, и вот что мы можем с этим сделать"».

Это сработало. Его негатив стал легитимным. Больше того — он стал ценным. Он перестал быть ворчуном, которого все избегают, и превратился в эксперта, к которому прислушиваются. Ему это понравилось. Мне — тем более.

Иногда, впрочем, скепсис — это крик о помощи. Человек выгорел, устал, потерял веру в профессию. Тогда нужен другой подход: не делегирование ответственности, а разговор по душам. «Слушай, я вижу, тебе тяжело. Что конкретно тебя беспокоит? Давай придумаем, как это исправить, а не просто хоронить идею». Иногда людям просто нужно, чтобы их выслушали.

Джун-энтузиаст, или Щенок, который может сгрызть продакшн

Это молодой специалист, только начинающий путь. У него горят глаза. Он готов работать сутками. Он верит, что этот проект — его шанс, его трамплин, его билет в светлое будущее. Он смотрит на Архитектора с обожанием, на Скептика — с недоумением, на вас — с надеждой.

Это прекрасный ресурс, но и прекрасный источник проблем. Без присмотра он может натворить таких дел в продуктивной среде, что седых волос прибавится у всей команды. Его энтузиазм гаснет при первой же жесткой критике. Он может уйти к конкурентам, как только получит предложение поинтереснее — если почувствует, что здесь его недооценивают.

Как с ним работать? Три простых правила.

Первое: четкие рамки и наставник. Никогда не давайте ему задачу «сделай модуль интеграции». Дайте: «Напиши юнит-тесты для модуля интеграции по вот этому шаблону. Старший коллега проверит через три дня, покажет ошибки, ты исправишь». Постепенно расширяйте зону ответственности, но всегда держите рядом того, кто подстрахует.

Второе: публичная похвала. Ему критически важно признание. Если он сделал даже мелкую задачу хорошо — скажите об этом на общем собрании. Это стоит ноль рублей, но дает топлива на месяц вперед.

Третье: карьерный трек. Поговорите с ним о его будущем. «На этом проекте ты научишься работать с интеграционной шиной. Следующий шаг — самостоятельная задача по разработке адаптера. Через год — позиция полноценного разработчика». Если он видит путь — он не уйдет.

Администратор-Аналитик, или Тихий хранитель порядка

Это человек, который любит, чтобы всё было на своих местах. Протоколы подшиты, задачи в трекере актуализированы, требования пронумерованы. Он интроверт, перфекционист и, возможно, немного зануда. Но именно он — ваш последний рубеж обороны от хаоса.

Его часто недооценивают. Считают скучным бюрократом, без которого можно обойтись. Пока он не уходит — и проект не тонет в море неподписанных протоколов, потерянных требований и забытых договоренностей.

Дайте ему власть над процессами документооборота. Скажите: «Без твоей визы ни один протокол не уходит заказчику. Ты — последний, кто проверяет, всё ли правильно оформлено. Если ты считаешь, что документ не готов, — я не подписываю». Это поднимет его статус в команде и даст чувство контроля над ситуацией. Ему это нужно. А вам нужен человек, который следит за порядком.

История шестая: «Пять чашек чая с драконом»

Теперь, когда мы разобрались с командой, перейдем к самой сложной части — отношениям с теми, кто изначально видит в вас угрозу. Я обещал рассказать эту историю еще в первой главе, и вот она.

Дело было на проекте внедрения системы документооборота в крупной компании. Технический директор заказчика — назовем его Иван Степанович — был классическим представителем своего вида. Он проработал в компании пятнадцать лет. Он помнил, на чем работал еще первый сервер. Он знал каждый патч, каждый костыль, каждую строчку кода в системах, которые мы должны были заменить. И он, конечно, был категорически против нашего проекта.

На первой встрече он даже не поздоровался. Просто сел в углу переговорной, открыл ноутбук и демонстративно начал что-то печатать, пока мы рассказывали о плане работ. Когда я спросил его мнение, он ответил: «Мое мнение — что это не взлетит. Но решать не мне, а генеральному». И снова уткнулся в экран.

Мои коллеги предлагали действовать через голову Ивана Степановича — обратиться к генеральному, объяснить ситуацию, попросить «приструнить» техдира. Это стандартный путь. И, как показывает практика, почти всегда проигрышный. Даже если генеральный директор надавит, техдир найдет способ отомстить. Затянет согласования, не выделит людей, будет топить нас на каждом техническом совещании.

Я выбрал другой путь. Я решил, что должен приручить этого дракона. И придумал план, который потом назвал «Пять чашек чая».

Чашка первая: признание власти и компетенций

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

Я не стал рассказывать о проекте. Вместо этого я сказал примерно следующее: «Иван Степанович, мы изучили документацию, но я понимаю, что реальная архитектура вашего ландшафта известна только вам. Никакие бумаги не расскажут того, что знаете вы. Без вашего совета мы рискуем наломать дров. Расскажите, какие грабли нас ждут? Где мы можем ошибиться? Что нужно сделать иначе, чем написано в нашем плане?»

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

В конце встречи он сказал: «Ну, вы хотя бы слушаете. Уже неплохо».

Чашка вторая: технический разговор на равных

Через две недели я пришел снова. На этот раз — с нашим архитектором. Мы принесли переработанную схему интеграции, в которой учли добрую половину замечаний Ивана Степановича.

«Вот, — сказал я. — Мы переделали вот этот узел, как вы советовали. А вот здесь у нас есть решение, но оно спорное. Что думаете?»

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

В какой-то момент он нашел реальную уязвимость в нашей схеме. Я честно признал: «Вы правы, этот узел надо резервировать. Спасибо, что заметили». Это был важный момент. Я не стал защищать свою правоту любой ценой. Я признал его правоту. И это сработало лучше любых дипломатических уловок.

Чашка третья: демонстрация быстрой победы

Через месяц мы пригласили Ивана Степановича на демонстрацию. Не презентацию — презентации он ненавидел. А именно демонстрацию: работающий прототип на тестовых данных.

«Помните тот спорный узел? — спросил я. — Мы его сделали. Можете сами попробовать».

Он сел за клавиатуру, запустил тестовый сценарий. Система отработала. Он попробовал еще один, нестандартный — она справилась и с ним. Он хмыкнул. Это было одобрительное хмыканье, я уже научился их различать.

Конкретный результат бьет любые слова. После этой демонстрации Иван Степанович перестал называть наш проект «провальным». Вместо этого он начал говорить: «Ну, посмотрим, что у них получится на реальных данных».

Чашка четвертая: просьба о помощи

Прошло еще полтора месяца. Мы наткнулись на странную проблему при интеграции с одним из legacy-модулей. Документация говорила одно, реальное поведение — другое. Разработчики бились неделю. Я знал, что могу попросить помощи у Ивана Степановича — но боялся, что это будет выглядеть как признание слабости.

И все-таки решился. Пришел и честно сказал: «Иван Степанович, мы уперлись в стену. Модуль авторизации ведет себя не так, как написано в документации. Мы перепробовали всё, что знали. Вы сталкивались с этим?»

Он посмотрел на меня с выражением, которое я бы назвал удовлетворением. «Конечно, сталкивался, — сказал он. — Документация старая, модуль допиливали три года назад, и никто не обновил описание. Сейчас покажу».

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

Чашка пятая: передача славы

За две недели до финальной приемки мы готовили презентацию для генерального директора. Я позвонил Ивану Степановичу: «Мы хотим отметить ваш вклад в проект на итоговой встрече. Можно я скажу, что без вашей экспертизы мы бы не справились?»

Он замялся. Потом сказал: «Ну, если вы считаете нужным...»

На встрече я сказал: «Особо хочу отметить вклад Ивана Степановича. Когда мы столкнулись с проблемой интеграции legacy-модуля, именно его экспертиза спасла нас от задержки в несколько недель. Без него проект не был бы сдан в срок».

Генеральный директор кивнул. Иван Степанович слегка покраснел, но было видно — ему приятно. С этого момента он стал нашим защитником. Когда через полгода встал вопрос о расширении системы, он сам предложил продолжить работу с нами. Не потому что мы были дешевле или быстрее. А потому что мы стали «своими».

Пять чашек чая. Пять встреч. От ненависти до сотрудничества — ровно пять шагов. Не всегда этот путь такой короткий. Иногда требуется больше времени. Но принцип работает всегда: не воюйте с драконом, приручайте его.

Мотивация без золотых монет

Теперь позвольте сказать несколько слов о том, о чем часто забывают. О мотивации.

Молодые руководители часто думают, что единственный способ мотивировать людей — это деньги. Премии, бонусы, повышения зарплаты. Деньги важны, спору нет. Но они не творят чудес. Точнее, творят, но недолго.

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

Вот что мотивирует людей на самом деле.

Первое — защита от хаоса. Когда руководитель встает между командой и разъяренным заказчиком и принимает удар на себя. Когда он говорит: «Я разберусь, работайте спокойно». Когда ошибка разработчика не превращается в публичную порку, а становится уроком, который разбирается внутри команды без оргвыводов. Команда должна знать: нас прикроют. Это доверие дороже любых премий.

Второе — признание заслуг перед высшим руководством. Если ваш сотрудник сделал что-то выдающееся — напишите письмо руководителю компании, поставив сотрудника в копию. «Хочу отметить вклад Ивана Петрова в успешную сдачу этапа. Иван в одиночку решил проблему совместимости протоколов, что сэкономило нам две недели сроков». Это письмо попадет в личное дело, его увидят коллеги, о нем узнает начальство. Это стоит дешевле любой премии, а эффект дает колоссальный.

Третье — развитие. Возможность учиться новому, ходить на конференции, получать сертификаты. Особенно это важно для молодежи. Скажите джуну: «Я договорился, тебе оплачивают курс по контейнеризации, потому что через полгода мы будем это внедрять». Он будет работать с утроенной энергией — потому что чувствует, что компания в него вкладывает.

Четвертое — просто человеческое отношение. Помнить о днях рождения. Спрашивать, как здоровье ребенка, если сотрудник брал больничный. Дать отгул после ночного релиза, не считая часы. Это не техники менеджмента, это просто порядочность. Но именно она создает ту невидимую связь, которая удерживает команду вместе, когда проект входит в шторм.

Трактат о статусе «Всё хорошо»

Теперь поговорим об отчетности. Нет, не зевайте. Это важно.

Представьте ситуацию: вы спрашиваете разработчика, как дела. Он отвечает: «Всё хорошо, работаю по плану». Вы спрашиваете через неделю — тот же ответ. Через две — то же самое. А за три дня до дедлайна вдруг выясняется, что задача готова процентов на сорок, и остальное доделать невозможно, потому что смежная система не отдает данные.

Почему так происходит? Потому что люди боятся сообщать плохие новости. Боятся наказания, разноса, потери лица. И вместо того чтобы вовремя поднять тревогу, они надеются, что «как-нибудь рассосется». Не рассосется. Проблемы не стареют — они гниют.

Я ввел в своей практике правило «честного светофора». Каждый статус-отчет содержит цветовую индикацию по каждой задаче. Зеленый — всё в порядке. Желтый — есть задержка или риск, но есть план восстановления. Красный — проблема, требуется помощь.

Главное правило: отчет, где по всем задачам «зеленый» больше двух недель подряд, вызывает у меня немедленное желание проверить всё лично. Потому что «всё хорошо» в нашем деле — это аномалия. Всегда есть какие-то заминки, вопросы, риски. Если их нет в отчете — их скрывают.

И второе правило: сообщить о проблеме в день ее обнаружения — это не ошибка, это доблесть. Скрыть проблему до дедлайна — преступление. Я говорю это команде на старте каждого проекта. И стараюсь подтверждать делом: если кто-то пришел с проблемой заранее, я не кричу, не наказываю, а помогаю решить. Люди быстро учатся. И постепенно культура замалчивания сменяется культурой открытости.

Справка: «Бумажный след» — магия, превращающая «авось» в доказательство

В конце этой главы — несколько слов об инструменте, который я считаю одним из главных в нашем деле.

«Бумажный след» — это правило, простое как дверь: после каждого устного разговора, имеющего значение для проекта, вы отправляете письменное резюме. Не длинное, не формальное. Достаточно трех-четырех предложений.

«Иван Степанович, спасибо за встречу. Резюмирую нашу договоренность: стороны согласовали перенос срока сдачи документации на пятнадцатое мая. Если у вас есть уточнения, прошу сообщить до завтрашнего вечера. В противном случае считаем дату согласованной».

Зачем это нужно? Затем, что пятнадцатого мая, когда заказчик скажет: «Я такого не говорил, мы договаривались на десятое», — вы достанете это письмо. И покажете. И отсутствие ответа на него. И это будет не ваше слово против его слова, а документированный факт.

Поначалу кажется, что это лишняя бюрократия. Но привыкаешь быстро. Потому что «бумажный след» — это не просто защита. Это уважение к договоренностям. Когда люди знают, что каждое устное обещание будет зафиксировано письменно, они начинают серьезнее относиться к тому, что говорят. Это дисциплинирует обе стороны. И это стоит потраченных пяти минут после каждой важной встречи.

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

Глава 6

Интеграционный ад, или Как заставить динозавров танцевать вальс

(Оперативное управление: стыковка систем, которые не предназначены для стыковки)

Есть момент в каждом проекте, который я про себя называю «точкой невозврата». Это когда первая строка вашего кода попадает на контур заказчика. Не на ваш уютный тестовый стенд, где всё настроено и отлажено. А на их сервер, с их настройками безопасности, их сетевыми ограничениями и их смежными системами, которые живут своей загадочной жизнью.

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

Эта глава — о том, как проходить эту фазу. О том, как интегрировать то, что не предназначено для интеграции. О том, как тестировать то, к чему у вас нет полного доступа. И о том, как в итоге сдать систему, даже если кажется, что это невозможно.

Техника «Костыль, который будет жить вечно»

Начну с истории, которая многое объясняет про природу интеграционных проектов.

Несколько лет назад мы делали проект для одного производственного холдинга. Нужно было связать новую систему управления заказами со старой учетной системой. Учетная система была написана в конце девяностых годов командой, от которой к тому моменту не осталось ни одного человека. Документации не было. Исходных кодов не было. Была только работающая программа, которую все боялись трогать.

Мы попросили доступ к API. Нам сказали: «Какой API? Эта система не умеет в API. Она умеет выгружать файлы в определенную папку на сервере раз в сутки». Мы спросили: «В каком формате файлы?» Нам показали. Это был бинарный формат, частично документированный в старой спецификации, которую нашли чудом — она лежала в кабинете уволившегося пять лет назад сисадмина.

Наш архитектор посмотрел на всё это, вздохнул и сказал: «Будем писать адаптер».

Адаптер — это программа-переводчик. Она берет данные в том виде, в котором их отдает старая система, и превращает в то, что может понять новая. Это как если бы вы наняли переводчика с языка, на котором говорили в Древнем Шумере, на современный русский. Задача непростая, но решаемая. Если, конечно, у вас есть хоть какие-то сведения о том, как устроен язык.

Мы написали адаптер за три недели. Он работал. Не идеально, но работал. Иногда он падал, когда в данных встречалось что-то неожиданное. Тогда мы добавляли новое правило, перезапускали — и он работал дальше. Постепенно мы покрыли все возможные варианты входных данных.

Когда проект закончился, мы передали адаптер в поддержку. Вместе с подробным комментарием в коде: «Этот модуль был написан такого-то числа таким-то разработчиком. Он парсит бинарный формат версии 3.2. Если что-то пойдет не так — смотрите логи, там подробно написано, на каком байте что пошло не так».

Прошло пять лет. Недавно я узнал, что этот адаптер до сих пор работает. Его никто не переписал, не заменил, не улучшил. Он просто делает свое дело. Это и есть «костыль, который будет жить вечно».

Кодекс чести «костыля»

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

Правило первое: костыль должен быть документирован. В коде должен быть комментарий, объясняющий, что здесь происходит и почему это сделано именно так. Не «// временное решение», а «// 2024-05-20, Петров А.С. Парсим HTML вместо использования API, потому что API v1.2 возвращает невалидный XML при запросе данных филиалов. Тикет в системе трекинга: INT-4521. Плановая дата замены на API v2.0 — после выхода релиза смежной системы, ориентировочно Q1 2025».

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

Правило третье: костыль должен иметь план замены. Даже если вы знаете, что этот план никогда не будет выполнен. Даже если вы понимаете, что «временное решение» простоит десять лет. Сама постановка вопроса «когда и как мы это исправим» меняет отношение к проблеме. Это перестает быть «грязным секретом» и становится осознанным компромиссом.

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

Я видел системы, в которых «временные заглушки» работали годами без единого сбоя, а «правильные архитектурные решения», пришедшие им на смену, падали каждый месяц. Не потому что архитекторы были плохими. А потому что реальность всегда сложнее, чем самая продуманная модель.

Искусство дебага без доступа к телу

Теперь поговорим о ситуации, с которой сталкивался каждый, кто работал в интеграционных проектах. Ваша система падает на контуре заказчика. Вы просите доступ к логам. Вам отвечают: «Доступ к серверу ограничен политикой безопасности. Логи мы вам пришлем». И присылают скриншот экрана с сообщением об ошибке. Один скриншот. На котором видно только «Error 500».

Знакомая картина? Мне — более чем. После нескольких таких случаев я выработал стратегию, которую называю «самодиагностика». Суть ее проста: ваша система должна уметь рассказывать о своем состоянии сама, без необходимости лезть в серверные логи.

Первое, что нужно сделать: встроить в приложение диагностическую страницу. Простой endpoint, который возвращает не просто «ОК», а детальный отчет о состоянии всех внешних зависимостей. Примерно такой:

«Статус: ЧАСТИЧНО ДЕГРАДИРОВАН. База данных: доступна, время отклика 15 мс. Очередь сообщений: доступна. Интеграция с учетной системой: ОШИБКА ТАЙМАУТА. Интеграция с банковским шлюзом: доступна. Свободное место на диске: 65%. Память: использовано 72%».

Когда заказчик звонит и говорит «у нас ничего не работает», вы просите его открыть эту страницу (она не требует специальных прав) и прислать вам результат. И вместо часового расследования вы за три минуты узнаете, что проблема не в вашей системе, а в том, что учетная система заказчика не отвечает. Это сразу снимает с вас обвинения и переводит разговор в конструктивное русло.

Второе: логи должны быть доступны. Не вам — заказчику. Настройте запись логов в отдельный файл на сетевой папке, доступной администраторам заказчика. Если система падает, вы говорите: «Откройте файл по такому-то пути, скопируйте последние пятьдесят строк и пришлите нам». Это не требует от вас доступа к серверу, но дает информацию для диагностики.

Третье: пишите логи на человеческом языке. Не «NullPointerException in module AB-234 at line 145», а «Ошибка подключения к учетной системе: сервер 192.168.1.100 не отвечает. Проверьте доступность сервера и повторите попытку». Представьте, что логи будет читать уставший администратор в три часа ночи. Пожалейте его.

Как тестировать то, к чему нет доступа

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

Как с этим жить? У меня есть несколько приемов.

Прием первый: «заглушки» с характером. Когда мы пишем эмулятор смежной системы для тестирования, мы обычно делаем его идеальным. Он всегда отвечает вовремя, всегда возвращает корректные данные, никогда не падает. А потом система выходит в реальный мир — и оказывается не готова к тому, что смежная система может отвечать медленно, с ошибками или не отвечать вовсе.

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

Прием второй: «серый ящик» вместо «черного». Если у вас нет доступа к внутренностям смежной системы, постарайтесь хотя бы понять, что у нее на входе и на выходе. Какие данные она получает, какие отдает, в каком формате, с какой периодичностью. Этого часто достаточно, чтобы локализовать проблему. «Мы отправляем запрос в формате JSON — система молчит. Мы отправили тот же запрос в формате XML — система ответила. Значит, проблема в формате данных, а не в сети».

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

Опытно-промышленная эксплуатация: Чемодан без ручки, который нельзя бросить

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

Я проходил через ОПЭ десятки раз и выработал три правила, которые помогают не сойти с ума на этом этапе.

Правило первое: программа испытаний — ваш закон

До начала ОПЭ у вас на руках должен быть документ под названием «Программа и методика опытной эксплуатации». Подписанный обеими сторонами. В нем должно быть прописано всё: сроки ОПЭ, критерии успешности, порядок фиксации замечаний, процедура их классификации и исправления.

Самый важный пункт — тот, который определяет, когда ОПЭ считается завершенной. Обычно это звучит так: «По истечении срока ОПЭ при отсутствии критических замечаний Система считается принятой в опытную эксплуатацию, Стороны подписывают Акт». Это защита от бесконечного «ой, мы еще не всё проверили, давайте еще недельку». Срок вышел, замечаний критических нет — подписываем.

Правило второе: классификатор дефектов

Каждое замечание, поступившее на ОПЭ, должно быть немедленно классифицировано. У меня есть простая система из трех категорий.

Критический дефект: блокирует бизнес-процесс, система не может выполнять свою основную функцию. Пример: не проводится платеж, не формируется обязательная отчетность. Такие дефекты исправляются немедленно, в режиме «все бросили и чиним». Срок реакции — не более суток.

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

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

Эту классификацию нужно согласовать с заказчиком до начала ОПЭ. Иначе любая опечатка будет подаваться как «система неработоспособна».

Правило третье: ежедневный пульс

На время ОПЭ я ввожу ежедневный ритуал. Каждое утро — короткая сводка для заказчика: что работало вчера, какие были инциденты, как они решены, что планируется сегодня. Это занимает пятнадцать минут, но дает два важных эффекта.

Во-первых, заказчик видит, что мы контролируем ситуацию. Что про каждый сбой известно, и по каждому идет работа. Это снижает тревожность и предотвращает панические звонки.

Во-вторых, это дисциплинирует нас самих. Нельзя написать «всё хорошо», если ты не проверил, что действительно всё хорошо. Ежедневный отчет заставляет держать руку на пульсе.

Приемка: танец с бубном у последнего рубежа

Вот он, момент истины. Проект длился год, команда вымотана, бюджет на исходе. Осталось подписать акт сдачи-приемки. Но у заказчика всегда есть замечания. Он боится подписывать, потому что после подписи ответственность переходит на него. Он будет тянуть, придираться к мелочам, требовать «доделать вон ту штуку». Это не технический, это психологический процесс. И к нему нужно быть готовым.

Тактика первая: Протокол разногласий

Заказчик говорит: «Не подпишу акт, пока не сделаете все сто процентов замечаний, включая цвет кнопки». Вы отвечаете: «Давайте подпишем акт сейчас. К акту прилагается Протокол разногласий — вот список оставшихся замечаний и сроки их устранения. Протокол является неотъемлемой частью акта. Закрытие протокола — это не срыв сдачи, а плановая работа в рамках гарантийных обязательств».

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

Тактика вторая: деление неделимого

Если у вас один большой этап «Разработка и внедрение», его трудно сдать целиком. Всегда найдется что-то недоделанное. Разбейте его на подэтапы: «Модуль интеграции», «Модуль отчетности», «Личный кабинет». Каждый подэтап закрывается отдельным актом. Легче подписать четыре маленьких акта, чем один большой. Если споткнулись на одном модуле — остальные уже сданы и оплачены.

Тактика третья: предновогоднее чудо

Мы уже говорили об этом в первой главе, но это стоит повторить. В российских компаниях есть два окна закрытия бюджетов: конец июня и конец декабря. Если ваш проект финансируется из годового бюджета, неосвоенные деньги сгорают. За две недели до конца полугодия ваш спонсор будет сам бегать за вами с просьбой подписать хоть что-нибудь, чтобы провести платеж. Готовьте акты к этим датам. Это не цинизм, это знание реальности.

Главное правило приемки

Приемка — это не экзамен, где нужно сдать идеальный продукт. Это фиксация состояния «достаточно хорошо для передачи в эксплуатацию». Если вы перфекционист — вы никогда не сдадите проект. Если вы циник — вы сдадите брак. Мудрость руководителя в том, чтобы найти точку равновесия: достаточно качественно для передачи, достаточно честно для спокойной совести.

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

Справка: Что такое «Очередь мертвых писем» и почему это важно

В конце этой главы — короткая справка о термине, который часто всплывает в интеграционных проектах.

Dead Letter Queue, или «очередь мертвых писем» — это специальное хранилище в системах обмена сообщениями. Когда ваша система отправляет сообщение смежной системе, а та не может его обработать (неверный формат, ошибка данных, таймаут), сообщение попадает не в «никуда», а в эту очередь. Там оно лежит и ждет, пока администратор его не прочитает и не решит, что с ним делать: исправить и отправить заново, проигнорировать или написать обработчик для такого типа ошибок.

Это очень полезный механизм. Без него сообщения просто теряются, и вы никогда не узнаете, что какая-то часть данных не дошла до адресата. А с ним у вас есть шанс заметить проблему и исправить ее до того, как она станет катастрофой. Хороший тон — настроить мониторинг очереди мертвых писем так, чтобы при появлении нового сообщения система сама отправляла уведомление администратору. Плохой тон — забыть про эту очередь и вспомнить только тогда, когда пользователи начнут жаловаться, что «данные куда-то пропали».

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

Глава 7

Сервис, или Как доить корову, которая хочет, чтобы ее зарезали

(Превращаем головную боль внедрения в стабильный источник радости и денег)

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

Через три дня позвонил заказчик. Система упала.

Я позвонил архитектору — он был в отпуске, в горах, без связи. Позвонил ведущему разработчику — он только что уволился и уехал в другую компанию. Позвонил администратору — он сказал, что его не предупреждали о необходимости поддерживать именно эту систему, у него еще три проекта висят.

Мы подняли систему через сутки. Но эти сутки стоили нам примерно половины той репутации, которую мы зарабатывали год. Заказчик больше не звонил нам с новыми проектами. Он звонил нашим конкурентам.

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

Эта глава — о том, как выстроить сервис так, чтобы он не стал ночным кошмаром. И о том, как превратить поддержку из обузы в источник дохода.

Переход в промышленную эксплуатацию: почему это самый опасный момент

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

Это и есть переход в промышленную эксплуатацию. Самый недооцененный этап проекта. Все устали, все хотят «закрыть и забыть». Но именно сейчас закладывается фундамент того, будут ли у вас с этим заказчиком долгие отношения или он уйдет к конкурентам при первой возможности.

У меня есть три столпа, на которых держится правильный переход. Не пренебрегайте ни одним.

Столп первый: эксплуатационная документация

Когда мы говорим «документация», мы обычно представляем себе толстые тома, которые никто не читает. Техническое задание, технический проект, программа испытаний — всё это нужно, но не для поддержки. Для поддержки нужна другая документация. Короткая, практичная, написанная так, чтобы ее мог понять уставший дежурный инженер в три часа ночи.

Что в нее входит?

Инструкция по установке и развертыванию. Не «установите систему согласно прилагаемому руководству», а пошаговый чек-лист. «Шаг первый: проверьте версию операционной системы командой такой-то. Шаг второй: убедитесь в наличии прав администратора. Шаг третий: скопируйте скрипт развертывания в директорию такую-то. Шаг четвертый: запустите скрипт командой такой-то. Если на шаге четвертом возникла ошибка — смотрите раздел "Типовые ошибки при установке"».

Инструкция администратора. Как мониторить систему, как смотреть логи, как перезапускать сервисы, как добавлять и удалять пользователей, как делать резервные копии.

И самое важное — инструкция по действиям в аварийных ситуациях. Я называю ее «плейбук». Это набор сценариев: «Если случилось А — делай Б». Симптом: не открывается главная страница. Действие первое: проверить, запущен ли сервис, командой такой-то. Если не запущен — запустить командой такой-то. Если не запускается — проверить свободное место на диске. Если места мало — очистить логи. И так далее, вплоть до эскалации на разработчика. Плейбук не заставляет человека думать спросонья. Он ведет его за руку.

И еще один важный документ — реестр известных проблем. Это список «граблей», на которые кто-то уже наступил, с указанием симптомов и решений. «Симптом: при загрузке файла появляется ошибка "Неверный формат даты". Причина: пользователь скопировал дату из Excel, где она была с точкой, а не с дефисом. Решение: использовать кнопку "Вставить из буфера", а не Ctrl+V». Когда такой реестр ведется, каждое новое обращение не становится расследованием с нуля.

Столп второй: передача знаний

Документация — это прекрасно. Но она не заменит живого общения. Передача знаний от команды внедрения команде поддержки должна быть живым процессом.

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

Второй элемент — разбор полетов. Каждый инцидент на этапе совместного дежурства разбирается не как «починили и забыли», а как учебный кейс. Почему это случилось? Как мы это нашли? Что нужно сделать, чтобы это не повторилось? Что нужно добавить в плейбук?

Третий элемент — «живой архив». Все решения по инцидентам записываются в базу знаний, доступную обеим командам. Через полгода эта база станет главным инструментом поддержки. Через год — бесценным архивом, который сэкономит сотни часов.

Столп третий: SLA, который вы реально можете выполнить

SLA — Service Level Agreement, соглашение об уровне сервиса. Это документ, в котором вы обещаете заказчику определенное качество поддержки. Время реакции, время решения, доступность системы. И это документ, который может вас разорить, если вы пообещали слишком много.

Самая опасная цифра — доступность. «Девяносто девять и девять десятых процента» звучит красиво. Но это означает, что система может не работать не больше сорока трех минут в месяц. Вы уверены, что дата-центр заказчика с его плановыми отключениями электричества обеспечит такую доступность? Если нет — не пишите эту цифру.

Пишите честный SLA. Такой, который вы можете выполнить с запасом.

Время реакции — это не время решения. Это время, за которое вы ответите на звонок или письмо. «Пятнадцать минут в рабочее время, тридцать минут в нерабочее». Это реально. Ответ может быть простым: «Мы получили ваше обращение, номер тикета такой-то, мы начинаем работать». Но он должен быть быстрым.

Время решения — привязывайте к приоритету. Критический инцидент (бизнес встал) — цель четыре часа. Средний (работа затруднена, но идет) — восемь рабочих часов. Низкий (косметика) — по согласованию, в рамках следующего релиза.

И обязательно — раздел «Исключения из SLA». «Настоящее соглашение не применяется в случаях: аварий на инфраструктуре Заказчика, проблем в смежных системах, не обслуживаемых Исполнителем, отсутствия доступа к контуру по вине Заказчика, наступления обстоятельств непреодолимой силы». Без этого раздела вы будете отвечать за чужой даунтайм.

Тайная жизнь службы поддержки

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

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

Расскажу историю. В одной компании, с которой мы работали, был инженер поддержки — назовем его Дмитрий. Он не был гениальным разработчиком. Но он умел слушать. Когда пользователь звонил с проблемой, Дима не просто решал тикет. Он спрашивал: «А почему вы вообще делаете эту операцию именно так? А что будет, если сделать иначе?». Он собирал обратную связь и раз в месяц присылал нам отчет: вот что пользователей реально раздражает, вот что они просят, вот что можно улучшить.

За год работы Дима «продал» доработок на сумму, вдвое превышающую его зарплату. Просто внимательно слушая людей и передавая их боль туда, где ее могли превратить в новые функции. А потом и в новые деньги.

Вывод: инвестируйте в поддержку. Нанмите туда толковых людей. Обучите их не только технике, но и общению. Создайте систему, в которой их наблюдения превращаются в продажи. Это окупится сторицей.

Три уровня поддержки

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

Первая линия — диспетчеры. Они принимают звонки и письма, регистрируют тикеты, проверяют по базе знаний. Если есть готовое решение — дают его. Если нет — передают дальше. Здесь не нужна глубокая техническая экспертиза. Нужны вежливость, внимательность и умение быстро ориентироваться в базе знаний.

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

Третья линия — разработчики и архитекторы. Они подключаются, когда нужна правка кода. Это дорогой ресурс, он должен быть защищен от рутины. Если разработчик третьей линии отвечает на вопрос «как сбросить пароль» — вы неправильно выстроили процесс.

Как разговаривать с пользователями

И еще один важный момент. Тон общения. Поддержка — это не только техника, это еще и психология.

Запрещенные фразы: «Это не баг, это фича», «Вы делаете что-то не так», «Это невозможно», «Мы не отвечаем за это». Каждая из них звучит как «вы дурак, а мы умные». Даже если вы правы по существу, вы проиграли по форме.

Правильный тон: «Я понимаю ваше замешательство, интерфейс здесь неочевидный. Давайте я покажу, как правильно». Или: «Это действительно ограничение текущей версии. Мы зафиксировали ваше пожелание и передали в отдел разработки. Возможно, в следующем релизе мы это улучшим».

Пользователь должен чувствовать, что его услышали. Что его проблема важна. Что он не дурак, а просто столкнулся с несовершенством системы, которое вы готовы исправлять. Это превращает раздраженного клиента в лояльного. А лояльный клиент — это тот, кто приходит к вам снова.

«Корзины возможностей»: как продавать доработки без стыда

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

Я использую формат ежемесячного «сервисного комитета» — короткой встречи с заказчиком, на которой мы обсуждаем качество поддержки. Помимо отчета по SLA, я приношу три «корзины возможностей».

Корзина первая: «То, что мы сделали бесплатно». В этом месяце мы ускорили загрузку реестра на двадцать процентов за счет оптимизации запроса. Это заняло восемь часов, мы сделали это без дополнительной оплаты, в рамках доброй воли. Заказчик видит, что мы не просто сидим на абонентской плате, а реально улучшаем систему. Он чувствует себя немного должным.

Корзина вторая: «То, что просится само». Анализируя обращения пользователей, мы видим, что тридцать процентов тикетов связаны с ошибками при ручном вводе контрагентов. Мы можем реализовать автоматическую подгрузку данных по ИНН из государственного реестра. Срок — три недели, бюджет — X рублей. Окупаемость за счет сокращения ошибок — четыре месяца. Это не навязанная продажа, это решение реальной боли, подтвержденной цифрами. Отказаться сложно.

Корзина третья: «Стратегическое развитие». Система работает стабильно, но мы видим потенциал. Мобильное приложение для согласования договоров. Предиктивная аналитика по платежам. Интеграция с новым порталом государственных услуг. Мы не продаем это здесь и сейчас. Мы сеем зерна. Когда у заказчика появится бюджет на развитие — он придет к нам, а не к конкурентам, потому что мы уже показали, что понимаем его потребности.

Такой подход превращает поддержку из затратного центра в центр прибыли. А заодно — делает отношения с заказчиком глубже и устойчивее. Потому что вы для него теперь не просто «те, кто чинит, когда ломается». Вы — партнер по развитию.

Справка: Реальные метрики и исключения из правил

В конце главы — несколько слов о том, как измерять качество поддержки. Метрик много, но я остановлюсь на трех, которые действительно важны.

Первая: среднее время решения, или MTTR — Mean Time to Resolution. Это время от момента регистрации тикета до момента, когда проблема решена. Важно смотреть на эту метрику в разрезе приоритетов. Критические инциденты должны решаться за часы, низкоприоритетные — могут за дни. Если вы усредняете всё в одну кучу — вы не видите реальной картины.

Вторая: доля решенных на первой линии. Сколько тикетов закрыли диспетчеры, не привлекая инженеров. Высокий показатель означает, что у вас хорошая база знаний и подготовленные люди на первой линии. Низкий — что вы гоняете дорогих инженеров отвечать на вопросы «как сбросить пароль».

Третья: удовлетворенность пользователя, или CSAT — Customer Satisfaction. После каждого закрытого тикета пользователю уходит короткий опрос: «Оцените качество решения проблемы по шкале от одного до пяти». Средний балл — ваш главный показатель. Всё остальное — техника. Если пользователи недовольны — система не работает, даже если все SLA соблюдены.

И еще одна вещь, которую стоит помнить. Любая метрика превращается в фарс, если ее начинают использовать для наказания. Если вы штрафуете за низкий CSAT — сотрудники начнут выпрашивать оценки у пользователей. Если вы требуете решать тикеты за час — начнут закрывать их как решенные, не решая. Метрики — это инструмент понимания, а не кнут. Пользуйтесь ими мудро.

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

Глава 8

Юридическая магия, или Как не превратиться в хорька в колесе Сансары Уголовного Кодекса

(Правовая самооборона для тех, кто хочет спать спокойно)

Был в моей практике случай, который я вспоминаю как поворотный. Не самый героический и не самый денежный, но — поворотный. Мы сдали проект. Не идеально, но в срок и в рамках бюджета. Заказчик принял, акт подписал, деньги перевел. Я уже мысленно праздновал, как вдруг мне звонит наш юрист и говорит: «Тут пришла претензия. Заказчик требует неустойку за срыв сроков на третьем этапе».

Я сначала даже не понял, о чем речь. Какой срыв сроков? Мы же всё сдали вовремя! Потом вспомнил: на третьем этапе действительно была задержка на две недели. Тогда у заказчика менялся технический директор, новый входил в курс дела, согласования шли медленно. Но мы же договорились устно! Мы же обсудили это на встрече! Новый техдир сказал: «Да, я понимаю, сроки сдвигаются, работайте спокойно». И мы работали. А теперь старый техдир ушел, новый делал вид, что ничего не помнит, а юристы заказчика тыкали пальцем в договор, где черным по белому было написано: «Срок выполнения этапа — не позднее 31 марта».

Доказательств устной договоренности у меня не было. Ни письма, ни протокола, ни даже короткой записки. Только моя память и ощущение несправедливости. Мы тогда заплатили неустойку. Небольшую по сравнению с бюджетом проекта, но очень обидную. Потому что формально заказчик был прав. А я — нет.

С тех пор я знаю: юриспруденция — это не скучное дополнение к нашей работе. Это её несущая конструкция. И если вы думаете, что «юридические вопросы решает юротдел», — вы заблуждаетесь. Юротдел решает вопросы, которые вы ему передали. А если вы не передали ничего, потому что не зафиксировали проблему на бумаге, — юротдел бессилен.

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

Трудовые будни: вы — надзиратель или пастух?

Начнем с того, что ближе всего к телу, — с Трудового кодекса. Молодые руководители часто думают: я не директор, я не подписываю трудовые договоры, значит, трудовое право — не моя забота. Опасное заблуждение.

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

О сверхурочной работе

Самая частая точка риска — переработки. Трудовой кодекс говорит: сверхурочная работа допускается с письменного согласия работника и в ограниченных пределах. Не больше четырех часов за два дня подряд и ста двадцати часов в год.

Что это значит для вас? Если вы пишете в общий чат: «Завтра всем быть в субботу, релиз горит!» — вы только что создали доказательство принуждения к сверхурочной работе. Если кто-то из команды пойдет в инспекцию по труду — у него на руках будет ваше сообщение. Дальше — штрафы, предписания, разбирательства.

Как надо? Написать иначе: «Коллеги, для успешного релиза в понедельник нужна работа в субботу. Это строго добровольно. Кто готов выйти — напишите мне лично, оформим приказ с оплатой согласно Трудовому кодексу. Кто не может — без проблем, обсудим перераспределение задач». И обязательно — бумага. Приказ о сверхурочной работе, завизированный уполномоченным лицом, и письменное согласие сотрудника. Да, это морока. Но эта морока отделяет вас от административного штрафа и испорченных отношений с сотрудником, который однажды решит, что его использовали.

О тоне общения

В аврале легко сорваться. «Ты что, издеваешься? Кто так код пишет? Переделывай!» Это не просто невежливо. Это может быть квалифицировано как оскорбление. А за оскорбление существует административная ответственность.

Кроме того, есть более тонкие материи. Шутки на грани, обсуждение внешности, политических взглядов, личных обстоятельств. Всё это в рабочем чате — не «дружеское общение», а мина замедленного действия. Скриншоты имеют свойство утекать. Причем именно тогда, когда они могут нанести максимальный ущерб.

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

О расставании

Если член команды не справляется, вы как руководитель инициируете его замену. Здесь важно понимать разницу между несколькими вариантами.

Увольнение за несоответствие должности — долгий и сложный путь. Требуется аттестация, подтверждающая недостаточную квалификацию. Это месяцы процедур и почти гарантированный суд.

Увольнение за неоднократное неисполнение обязанностей — тоже сложный путь. Нужны дисциплинарные взыскания, акты, объяснительные. Бумаг должно быть много, и все они должны быть оформлены правильно.

Соглашение сторон — самый цивилизованный способ. Вы говорите: «Мы видим, что проект тебе не подходит. Давай расстанемся по-хорошему. Ты получаешь выходное пособие и нормальную характеристику, мы — спокойствие и возможность взять нового человека». В большинстве случаев это работает. Люди не хотят скандалов, если с ними разговаривают по-человечески.

Моя роль как руководителя проекта — собрать факты и передать их в отдел кадров. Но ни в коем случае не угрожать увольнением, не обещать «золотые горы» и не принимать кадровые решения единолично. Это не моя компетенция.

Договор-убийца и как его обезвредить

Теперь перейдем к самому главному документу в любом проекте — договору. Тому самому, который подписывает генеральный директор, а исполнять приходится вам.

Я не призываю вас становиться юристом. Но я призываю вас прочитать договор. Весь. Включая то, что написано мелким шрифтом в приложениях. Потому что именно там часто скрываются вещи, которые потом превратят вашу жизнь в ад.

На что смотреть в первую очередь

Первое: предмет договора. Что именно мы обязались сделать? Если там написано «Разработка и внедрение системы автоматизации», а вы думаете, что аналитический модуль — это отдельный проект, у вас проблемы. Предмет договора — это ваша Библия. Всё, что туда входит, вы обязаны сделать. Всё, что не входит — не обязаны.

Второе: сроки и ответственность за их нарушение. Обычная формулировка: «За нарушение сроков выполнения работ Подрядчик уплачивает Заказчику неустойку в размере ноль целых одной десятой процента от стоимости невыполненных работ за каждый день просрочки». Звучит нестрашно, да? А теперь посчитаем. Цена контракта — тридцать миллионов рублей. Вы просрочили этап на месяц. Тридцать миллионов умножаем на ноль-один процент и на тридцать дней. Девятьсот тысяч рублей. За один месяц опоздания. А если просрочка в три месяца — два миллиона семьсот тысяч. Всё еще нестрашно?

Что этому противопоставить? Пункт о встречных обязательствах Заказчика. «Сроки выполнения работ продлеваются соразмерно задержке предоставления Заказчиком необходимой информации, доступов, согласований». Если такого пункта в договоре нет — бейте тревогу. Настаивайте, чтобы его добавили. Без него любой чих со стороны заказчика, задерживающий вашу работу, формально не освобождает вас от ответственности.

Третье: порядок сдачи-приемки. Как именно работы считаются принятыми? Что такое «мотивированный отказ» от приемки? Сколько дней есть у заказчика на проверку? Если он молчит — работы считаются принятыми автоматически или нет?

Хороший договор содержит фразу: «Если в течение десяти рабочих дней с момента получения Акта сдачи-приемки Заказчик не подписал Акт и не предоставил мотивированного отказа, работы считаются принятыми». Это ваша «ядерная кнопка», о которой мы говорили в главе про приемку. Но она должна быть предусмотрена договором.

Чего нельзя делать никогда

Подписывать дополнительные соглашения. Это делает только генеральный директор или человек с нотариально заверенной доверенностью. Ваша подпись на допсоглашении — это повод признать сделку недействительной. А в худшем случае — повесить на вас финансовую ответственность.

Обещать устно то, что противоречит договору. Сказали: «Да, доделаем этот модуль бесплатно» — а по договору это дополнительные работы? Вы только что создали проблему. Заказчик потом скажет: «Ваш сотрудник обещал» — и будет формально прав. Суд может взыскать стоимость этих работ с компании, а компания — с вас.

Брать на себя ответственность за чужие системы. Если вы подписываете акт, в котором написано «Система полностью работоспособна и совместима со всеми элементами ИТ-инфраструктуры Заказчика», — вы берете на себя ответственность за то, чего не знаете и не контролируете. Правильная формулировка: «Система функционирует согласно ЧТЗ при условии эксплуатации в среде, описанной в Техническом проекте».

Импортозамещение как стихийное бедствие

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

У меня был проект, который начался на западном стеке, а закончиться должен был уже на отечественном. Посередине мы получили директиву от службы безопасности заказчика: «Перейти на импортозамещенный стек в течение трех месяцев». Не предупреждение, не рекомендация — директива. Три месяца. На переписывание половины кода.

Если бы в договоре не было пункта про изменение технологического стека — мы бы делали это за свой счет. Но мы такой пункт предусмотрели. Звучал он примерно так: «Технологический стек проекта зафиксирован в Приложении таком-то. Изменение стека по инициативе Заказчика является существенным изменением условий Договора и влечет пересмотр сроков и бюджета». Это спасло нас от убытков.

Что нужно знать про реестры

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

Проверяйте это на старте. Задайте заказчику прямой вопрос: «Есть ли у вас директива по импортозамещению? Какой процент отечественного ПО мы должны обеспечить? Какие реестры применимы к нашему проекту?» Если этой дискуссии не было на старте, она случится в середине — и вы будете переписывать архитектуру на ходу.

Сертификация и лицензии

Если ваша система обрабатывает персональные данные — применяется закон о персональных данных. Если она относится к критической информационной инфраструктуре — применяется закон о безопасности КИИ. И там, и там есть требования по сертификации средств защиты информации, аттестации объектов и лицензированию деятельности.

Всё это — время. Сертификация может занимать от трех до двенадцати месяцев. Если вы не заложили это в план — вы срываете сроки не по своей вине, но с юридическими последствиями. Ваша задача — на старте задать вопросы: «Кто проводит аттестацию? Какие требования к средствам защиты? Входят ли работы по аттестации в наш объем?» Ответы должны быть зафиксированы. Письменно.

Маленький кодекс «Бумажного следа»

В конце этой главы позвольте резюмировать главный юридический принцип нашей профессии. Он состоит из трех простых правил.

Правило первое: всё, что не записано на бумаге, не существует. Устная договоренность — это прекрасно, пока отношения хорошие. Когда отношения портятся, устная договоренность превращается в «я такого не говорил». Поэтому: после каждого значимого разговора — письменное резюме. После каждого решения — протокол. После каждого изменения — дополнительное соглашение. Это не бюрократия, это страховка.

Правило второе: бумага должна быть правильной. Не «мы обсудили и договорились», а «Стороны согласовали следующие изменения: пункт такой-то изложить в такой-то редакции. Сроки выполнения работ продлеваются на такой-то период». Формулировки имеют значение. Если вы не уверены в формулировке — покажите юристу.

Правило третье: бумага должна быть у обеих сторон. Документ, который есть только у вас, — это не документ, а ваша личная запись. Документ, подписанный обеими сторонами, — это доказательство. Всегда добивайтесь, чтобы ключевые документы были подписаны обеими сторонами. И храните их. Даже после закрытия проекта. Даже через пять лет. Потому что исковая давность по хозяйственным спорам — три года. А по некоторым — и больше.

Я не призываю вас становиться параноиком. Я призываю вас быть профессионалом. Профессионал тем и отличается от любителя, что делает скучную работу вовремя. Скучную работу по документированию, согласованию, подписанию. Любитель думает, что пронесет. Иногда проносит. А иногда — нет. И тогда любитель превращается в обвиняемого.

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

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

Глава 9

Путь странника, или От подмастерья до Магистра

(Карьера, личный бренд и искусство не сойти с ума по дороге)

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

Это был первый звоночек. Я тогда не знал, что это называется выгоранием. Думал — просто устал, надо взять отпуск. Взял. Отпуск кончился — ощущение вернулось. Более того, усилилось. Я начал раздражаться на коллег, на заказчиков, на сам процесс работы. Любая мелочь выводила из себя. Проекты шли всё хуже, хотя формально я делал всё правильно. Я знал теорию, я умел применять её на практике — но что-то внутри сломалось.

Потом была история с панической атакой прямо на совещании. Я сидел, слушал доклад о статусе проекта, и вдруг сердце забилось где-то в горле, воздух стал густым, а стены переговорной — подозрительно близкими. Я извинился, вышел, дошел до туалета и просидел там полчаса, пытаясь понять, что со мной происходит. Тогда я впервые серьезно задумался: а стоит ли игра свеч?

С тех пор прошло много лет. Я не ушел из профессии. Более того, я научился получать от нее удовольствие — возможно, даже большее, чем в начале пути. Но путь этот стоил мне нескольких важных уроков. О них и пойдет речь в этой главе. Потому что какая польза от всех знаний, собранных в этой книге, если вы не сможете применить их — потому что выгорели, потеряли интерес или просто устали так, что никакой проект уже не в радость?

Волшебный чемоданчик: практические навыки

Начнем с простого и конкретного. С того, что можно пощупать руками. С инструментов.

Когда я начинал, профессия руководителя проектов была устроена иначе. Достаточно было уметь составлять графики, считать бюджеты и разговаривать с людьми. Техническая часть была зоной ответственности разработчиков и архитекторов. Сейчас этого недостаточно. Рынок требует от руководителя проектов всё более глубоких технических знаний. Не потому что вы должны заменить разработчика. А потому что вы должны понимать, о чем говорят ваши люди. И, что важнее, — понимать, когда они пытаются вас обмануть.

Я не призываю вас становиться программистом. Но есть минимальный набор инструментов, которыми стоит владеть.

Первое: системы управления задачами. Не просто «умею создать задачу в Jira», а полноценное администрирование проекта: настройка workflow, экранов, прав доступа, досок. Умение писать запросы на языке JQL, чтобы вытащить любую аналитику без помощи администратора. В последние годы появились российские аналоги — Яндекс Трекер, Kaiten, другие. Принципы те же, интерфейсы разные. Освойте хотя бы один инструмент глубоко — остальные освоите по аналогии.

Второе: средства работы с API. Самый простой — Postman или его бесплатные аналоги. Вы не должны писать код, но вы должны уметь «пощупать» API руками. Отправить запрос, получить ответ, посмотреть, что приходит на самом деле. Это снимает половину споров: вместо «ваша система не отдает данные» вы говорите: «Я отправил запрос — вот ответ. Данные отдаются, но не в том формате, который вы ожидаете. Давайте разбираться, где расхождение».

Третье: базовый SQL. Совсем базовый. SELECT, JOIN, WHERE, GROUP BY. Достаточно, чтобы проверить, есть ли данные в таблице, которую ваш интеграционный поток должен был заполнить. Достаточно, чтобы не полагаться на слова «данные потерялись», а открыть базу и посмотреть своими глазами.

Четвертое: средства мониторинга. Grafana, Prometheus, Kibana — если не настраивать, то хотя бы читать дашборды. Понимать, где смотреть нагрузку на сервер, количество ошибок, время отклика. Это дает вам независимую картину происходящего. Когда заказчик говорит «система медленная», вы открываете дашборд и говорите: «Среднее время отклика — двести миллисекунд. Медленно стало вот здесь, на этом графике, вчера в 14:30. Что произошло вчера в 14:30?»

Пятое: основы DevOps. Вы не обязаны уметь настраивать Kubernetes-кластер. Но вы должны понимать, чем контейнер отличается от виртуальной машины, зачем нужен CI/CD пайплайн и почему сборка может «упасть» на этапе тестирования. Это понимание кардинально меняет качество планирования: вы перестаете закладывать на «развертывание» полдня, потому что знаете, что в правильно настроенном пайплайне это занимает пятнадцать минут.

Как всё это освоить? Постепенно. Не нужно записываться на десяток курсов одновременно. Выберите один инструмент, который нужен прямо сейчас в текущем проекте, и изучите его. Через месяц — следующий. За год наберется приличный арсенал.

Личный бренд: ваши следы на песке времени

Теперь о вещах менее осязаемых, но не менее важных. О репутации.

Российский ИТ-рынок устроен как большая деревня. Все ключевые игроки знают друг друга лично или через одно рукопожатие. Когда вы ищете новый проект или новую работу, звонок знакомому руководителю сработает в сто раз быстрее, чем резюме на рекрутинговом сайте. Это не значит, что резюме не нужно. Это значит, что репутация — ваш главный актив.

Из чего она строится? Из сданных проектов, разумеется. Но этого мало. Нужно, чтобы о ваших проектах знали. Не в смысле «хвастаться на каждом углу», а в смысле «делиться опытом».

Простой способ начать: пишите пост-релизы. После каждого завершенного проекта — короткий текст. Не с грифом «секретно», а обезличенный, с разрешения клиента. «Завершили миграцию пяти тысяч пользователей на отечественный стек. Срок — четыре месяца. Ключевые уроки: первое, второе, третье». Это не занимает много времени, но через пару лет у вас набирается портфолио из десятка таких заметок. Когда потенциальный работодатель или клиент спросит: «А что вы умеете?» — вы не будете рассказывать на словах, вы просто покажете: вот, читайте.

Второй шаг: публичные выступления. Не обязательно сразу на большую конференцию. Начните с внутреннего митапа в своей компании. Расскажите о каком-то кейсе — не «какие мы классные», а «какую проблему мы решали и как». Коллеги зададут вопросы, вы поймете, что интересно аудитории, а что нет. Потом — региональная конференция. Потом — отраслевая.

Тема доклада должна быть конкретной. Не «Управление проектами в современных условиях», а «Как мы стыковали 1С с банковским шлюзом за две недели: три граблей и решения». Чем конкретнее тема, тем больше пользы слушателям и тем выше ваша репутация.

Третий шаг: профессиональный канал в мессенджере. Короткие заметки раз в неделю. О реальных кейсах, о прочитанном, о мыслях по поводу профессии. Это дисциплинирует мышление и создает архив ваших идей. Когда через год вас спросят: «Что вы думаете о такой-то проблеме?» — вы скажете: «Я как раз писал об этом, вот ссылка».

Важный момент: личный бренд — это не селфи с конференций. Это не «посмотрите, какой я успешный». Это «посмотрите, какие задачи я решаю и как я это делаю». Это не самолюбование, а профессиональная щедрость. Делитесь опытом — и опыт будет возвращаться к вам. В виде предложений о работе, приглашений в интересные проекты, вопросов от коллег, которые потом становятся партнерами.

Демон Выгорания

Теперь — о самом трудном. О том, о чем не принято говорить на конференциях и в корпоративных чатах. О выгорании.

Я не психиатр и не психолог. Я расскажу только то, что пережил сам, и то, что помогло мне. Возможно, это поможет и вам.

Выгорание не приходит внезапно. Оно подкрадывается постепенно, как туман. Сначала вы перестаете радоваться успехам. Ну сдали проект — и сдали. Раньше это был праздник, теперь — просто строчка в резюме. Потом вы начинаете цинично отзываться о заказчиках, о команде, о самой работе. «Да что они там понимают», «всем что-то надо, а я один за всех отдуваюсь», «гори оно всё синим пламенем». Вы думаете, что это просто профессиональный юмор. Но за этим юмором — пустота.

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

Потом — эмоциональная тупость. Ни радости, ни злости. Ровный ноль. Вы сидите на встрече и понимаете, что вам всё равно, примут проект или нет. Это самый опасный симптом.

Что я сделал, когда понял, что попал в эту воронку? Не сразу, но сделал.

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

Второе: установил нерушимый ритуал. Один час в день, который принадлежит только мне. Не телефону, не почте, не проектам. Час на прогулку, или на книгу, или на музыку. Это гигиена психики, как чистка зубов. Если я пропускаю этот час несколько дней подряд — знаю, что иду к обострению.

Третье: физическая активность. Не спорт высоких достижений, а просто движение. Бассейн два раза в неделю. Или десять тысяч шагов пешком с аудиокнигой. Тело должно уставать физически, чтобы голова отдыхала. Это не совет из модного журнала — это работает.

Четвертое: «стоп-слово». У меня есть договоренность с самим собой. Если я три раза за день произношу про себя фразу «Как же меня всё достало», я останавливаюсь. Беру день отдыха. Без чувства вины, без мысли «как же проект без меня». Проект проживет день. А я так, может быть, проживу дольше.

Пятое: смысл. Самое трудное. Когда ты выгорел, никакого смысла не видно. Но он есть. Он не в сдаче очередного проекта и не в квартальной премии. Он в том, что ты делаешь что-то, что помогает людям. Пусть опосредованно. Пусть через цепочку «система заработала — бухгалтер перестал плакать по вечерам — у него появилось время на детей». Мы редко видим конечный результат своей работы. Но он есть.

И последнее. Если вы чувствуете, что не справляетесь сами, — идите к специалисту. К психотерапевту. Это не стыдно. Это такая же медицинская помощь, как визит к стоматологу. Никто не говорит: «Я сам вылечу зуб». Но почему-то с психикой многие пытаются справиться самостоятельно. Не надо так. Если туман стал слишком густым — попросите помощи.

Эпилог

Прощание с Лабиринтом

Рано или поздно наступает момент, когда вы уходите. Из компании, из проекта, из роли. Это нормально. Средний срок жизни руководителя проектов на одном месте — два-три года. Дальше — либо рост, либо застой, либо выгорание. То, как вы уйдете, определит вашу репутацию на годы вперед.

Я видел людей, которые хлопали дверью, громко обвиняли начальство и заказчиков — и потом годами не могли найти работу, потому что слухи в нашей деревне расходятся быстро. И видел тех, кто уходил тихо, передав дела так, что проект не заметил их отсутствия. О них потом слагали легенды.

Как уйти правильно?

Первое: предупредить заранее. Две недели — минимум по Трудовому кодексу. Для руководителя проекта, который ведет сложный проект, нормально предупредить за месяц. Сказать руководителю лично, до официального заявления. «Я принял решение двигаться дальше. Это не импульсивное решение, я всё обдумал. Моя задача сейчас — сдать проект и передать дела так, чтобы мой уход не создал проблем».

Второе: подготовить преемника. Если вам не назначили сменщика, составьте «пакет передачи дел». Текущее состояние проекта: что сдано, что в работе, какие риски, какие открытые вопросы. Контакты ключевых людей на стороне заказчика. Доступы, пароли, ссылки на репозитории. Список «невидимых мин»: вот этот пункт договора трактуется двояко, вот этот техдир требует особого подхода, вот здесь обещали доделать, но не успели — надо проконтролировать.

Третье: закрыть хвосты. Доделать всё, что можно доделать за оставшееся время. Если что-то невозможно — честно написать об этом в пакете передачи. Никаких «авось рассосется». Не рассосется.

Четвертое: не сжигать мосты. На прощальной встрече сказать спасибо. Даже если есть за что ругать. Даже если душат обида и разочарование. Мир тесен невероятно. Сегодняшний обидчик завтра может стать заказчиком. Фраза «я ухожу за новым опытом, но всегда открыт для добрых отношений» — это страховка на будущее. Она ничего не стоит, но может принести неожиданные дивиденды.

И самое важное. Уходя, помните: проект — это не вы. Вы — не проект. То, что проект не закрыт или закрыт не идеально, — не повод оставаться в компании, которая вас разрушает. Ваша жизнь важнее любого акта сдачи-приемки.

На этом книга заканчивается. Текст, который вы только что прочитали, — это не инструкция. Это разговор. Разговор человека, который прошел этот путь, с теми, кто идет по нему сейчас.

Я не знаю, в каком вы сейчас состоянии. Может быть, вы только начинаете — и полны надежд. Может быть, вы в середине пути — и устали так, что не видите света в конце тоннеля. Может быть, вы на перепутье и думаете, куда двигаться дальше. Что бы ни было — вы не один. Этот лабиринт проходили до вас, проходят сейчас и будут проходить после. И каждый находит свой путь.

Помните только: документы решают всё. Но люди — важнее документов. А ваше собственное состояние — важнее любых проектов. Берегите себя. И удачи.