Рассмотрим следующую ситуацию: вы — проджект-менеджер, и на вашем проекте возникла проблема. О том, как поэтапно добраться до источника проблемы и ликвидировать ее, я подробно расскажу в сегодняшней статье.
У меня все работает!
Существует расхожее мнение, что проблемы решают исполнители, а управленцы только ходят и мешают. Однако что происходит, если на проекте нет менеджера? Представим ситуацию: в саппорт приходит гневное письмо: «Я нажал на кнопку, а там 500-я ошибка!». Причем письмо приходит не одно, то есть проблема массовая.
Кому отдать багу? Допустим, саппорт предполагает, что проблема произошла на клаент-сайде, и отдает багу JavaScript-программисту. JavaScript-программист смотрит описание и говорит: «Скорее всего, проблема на сервере. Я тут ни при чём». Сотрудник техподдержки кивает и отправляется к серверному программисту. Серверный программист, в свою очередь, заявляет, что на сервере проблем нет, код надежный, все должно работать. Саппорт отправляется к админу. Админ смотрит загрузку процессора, дисков, свободное место, логи, но также не находит ничего криминального.
Начиная с этого момента проблема, возникшая на проекте, как бы «ни на чьей стороне»: никто не считает себя ответственным и не считает необходимым браться за ее решение. И всех можно понять: у каждого есть свои таски, план по разработке, к тому же пилить новые фичи куда интереснее, чем разбираться с таинственной пятисотой, которая ну уж точно не по твоей вине появляется. В итоге все молодцы и заняты делом — вот только у пользователя все по-прежнему плохо.
Разумеется, это не единственный возможный ход развития сценария. Существуют команды, в которых нет человека с должностью проджект-менеджер, но проблемы, тем не менее, решаются. Однако происходит это благодаря тому, что один из членов команды фактически выполняет функции менеджера.
Итак, как изменится описанная выше ситуация, если предположить, что ПМ на проекте все же есть?
Правило #1: любая проблема становится вашей
Прежде всего, мы нашли владельца проблемы: это, собственно, ПМ. Все технари могут быть уверены, что проблема не у них, но проджект-менеджер обязан считать любую проблему пользователей своей личной проблемой.
Правило #2: пользователи никогда не врут
Это важно помнить: как бы безумно ни выглядел репорт, особенно если он не единственный в своем роде, в нем, вероятнее всего, написана правда.
Правило #3: никому нельзя верить… кроме пользователя
Этот тезис в стиле доктора Хауcа очень хорошо объясняется на рассматриваемой ситуации: если поверить всем, кого обошел саппорт, пытаясь добиться истины, то окажется, что проблемы ни у кого нет. Но ведь мы помним, что пользователи не врут!
Правило #4: решаем проблему сверху
После того, как мы выяснили, что проблема есть и она наша, неплохо бы начать ее решать. Начинать надо всегда сверху, то есть с того места, где проявляется симптом. В нашем случае симптом — то, что пользователь жмет на кнопку, а в качестве результата получает 500-ю ошибку.
Разумеется, если мы поставим заглушку, которая спрячет от пользователя пятисотый ответ от Ajax-конца, это никак не решит проблему (не говоря уже о том, что пользователь все равно рано или поздно об этом узнает и, конечно, пожалуется). Из этого следует пятое правило ПМа.
Правило #5: устраняем не симптом, а причину
В рассматриваемой ситуации, чтобы докопаться до причины, менеджер отправляется к верстальщику и выясняет, в каких именно случаях тот выводит на UI пятисотую ошибку. Что на это ответит верстальщик? «Когда я получил от сервера неправильный ответ». — «Хорошо, а какой ответ ты получил от сервера?» — интересуется ПМ. «Статус 500», — отвечает верстальщик. Здесь у нас наконец-то появляется какая-то информация: пользователь видит пятисотую ошибку, когда сервер возвращает ответ с кодом 500. Если это действительно так (а мы помним, что верить никому нельзя), необходимо выяснять, что происходит с сервером, когда он начинает так себя вести.
Правило #6: принцип наибольшей лени
Поскольку проджект-менеджер должен действовать, исходя из принципа наибольшей лени, в этот момент нужно поверить client-side программисту и пойти дальше.
Правило #7: проблема — это зона ответственности ПМ
Как может на этом этапе действовать условный неопытный ПМ? Попытаться отправить верстальщика к серверному программисту в надежде, что «они там как-нибудь между собой договорятся».
Что происходит, если разработчиков предоставить самим себе? Верстальщик приходит к серверному программисту, сообщает о 500-й ошибке и получает ответ: «А, ну, это все база». Верстальщик соглашается: «Ну да, дело в базе». После этого оба расходятся дальше программировать — ведь виновата во всём база (причем не факт, что это правда, а даже если и так — пользователю от этого не легче). После этого проходит день, два, неделя… Все это время менеджер свято уверен, что проблема устранена. Уверен до тех пор, пока не получает от техподдержки очередное гневное письмо, в котором пользователь жалуется на ту же проблему. В этот момент наш условный ПМ думает: «Как так? Но мы же всё выяснили!». Так он приходит к седьмому правилу проджект-менеджера: я решаю проблемы, остальные люди не обязаны их решать. Хорошо, если решат, но не обязаны.
Поэтому хороший проджект-менеджер должен в этой ситуации сам пойти к программисту.
Правило#8: логируем каждый шаг
Программист ему, естественно, скажет, что причин для пятисотой ошибки масса, а доступа к логам с продакшена у него нет, так что выяснить, в чем дело, он не в силах. Здесь необходимо небольшое лирическое отступление: наличие логов существенно упрощает жизнь как разработчикам, так и менеджеру. Отсутствие доступа к логам с продакшена у программиста — проблема решаемая. Довоз логов из продакшена в девелоперскую сеть можно настроить, и нужно всеми доступными методами мотивировать разработчиков через админов это организовать. Их можно почистить от кук, пользовательских данных и всего остального лишнего, но логи должны обязательно приезжать.
Рассмотрим самый хардкодный вариант: менеджер на проекте недавно, импорт логов никто не настроил, и данные с продакшена только на продакшене и есть. Выход один: идти к админам и просить логи. Предположим, у нас не все так плохо, и логи все же есть; однако в них лаконично написано: «500» — и больше ни слова.
Правило#9: не забывать о главном
Следующая ошибка, которую может совершить менеджер – сказать программисту: «Ок. Сделай логирование», — и забыть о проблеме. К чему это приведет? Во-первых, все случаи разработчик логированием, конечно же, не покроет, а во-вторых, в процессе разработки логирования он о самой исходной проблеме, разумеется, забудет.
Правильный план поведения в этой ситуации таков: добиться от разработчика, чтобы он рассказал, в какие ещё сервисы, базы данных и бэкенды он ходит, где может возникнуть ошибка. После этого все возможные случаи должны быть аккуратно залогированы. Если эта проблема на живом, то логировать нужно быстро, и сразу же выкатывать хот-фиксы.
Итак, логи записаны, и из них становится ясно, что сервис не смог сходить в какую-то базу или в другой сервис. В этот момент есть два варианта: показать логи разработчику, чтобы он разобрался сам, либо погрузиться в архитектуру и выяснить все самостоятельно.
После того как с помощью логов, админов и других подручных средств источник проблемы найден, необходимо непосредственно перейти к решению проблемы. В нашем случае это может быть как оптимизация SQL-запросов или использования API, так и что-то до обидного простое: возможно, ошибка появляется в результате того, что разработчик ходит в сервис авторизации и передаёт туда неправильный IP клиента.
Правило #10: убедиться, что симптомы исчезли
После того, как вероятная причина ошибки выявлена, менеджер препоручает ее решение ответственному за этот участок системы. Теперь самое главное – убедиться, что симптомы пропали. Убедиться в этом можно только одним способом — узнать у репортера бага, все ли Ок. Только после этого проблему можно считать решенной.
Идеальный менеджер в вакууме
В моем изложении проджект-менеджер получился своебразным супергероем от IT, который все делает сам: и логи смотрит, и архитектуру знает, и проблему может в случае чего сам решить. Такие случаи бывают, но, конечно, это не обязательно. В основном менеджеров окружают вменяемые профессионалы, которые могут сами что-то посмотреть и пофиксить. Но, тем не менее, важно помнить то, с чего мы начинали: разработчики склонны считать, что проблема не на их стороне, а проджект-менеджер любую пользовательскую проблему считает своей болью. И действует соответственно.
Не технарями едиными
Еще один немаловажный вывод из моего рассказа: проджект-менеджер не обязательно должен быть технарем. Для того чтобы сказать себе «я отвечаю за любую проблему», «пользователи никогда не врут» и «верить никому нельзя», не нужно обладать особыми техническими скиллами. Польза от технического бэкграунда, конечно, есть – он выстраивает нужном направлении и помогает понять, когда именно нельзя верить никому – но это не является критичным для менеджера. Кроме того, зачастую в процессе решения проблемы задача оказывается настолько разжеванной для разработчиков, что они уже и сами понимают, как ее решить, и никаких управленческих решений не требуется.
В следующих сериях
В этой статье я поделился своими соображениями по поводу решения проблем на проекте с точки зрения проджект-менеджера. У ПМа есть много других интересных задач: как управлять сроками и рисками, как быстро и качественно делать новые фичи. Об этом я постараюсь рассказать в следующих статьях.
Денис Аникин,
технический директор Почты Mail.Ru
Автор: danikin
