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