Решение проблем: 10 правил менеджера

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



    У меня все работает!

    Существует расхожее мнение, что проблемы решают исполнители, а управленцы только ходят и мешают. Однако что происходит, если на проекте нет менеджера? Представим ситуацию: в саппорт приходит гневное письмо: «Я нажал на кнопку, а там 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
    Mail.ru Group
    769.95
    Building the Internet
    Share post

    Similar posts

    Comments 84

    • UFO just landed and posted this here
        +14
        «Нельзя просто так брать и везде ставить эту картинку». Хотя можно конечно, просто страсть как надоела.
        +22
        Правило #2: пользователи никогда не врут

        Конечно же врут, они забыли указать в репорте что запускают вручную скомпилированный браузер с кучей странных add-on'ов из под wine, который под vmware, за squid с нестандартными настройками, за корпоративным файрволом. А до этого вручную копировали cookies туда-сюда, редактировали Location у браузера, баловались с firebug и прописали google analytics в /etc/hosts, чтобы избавиться от вируса на компьютере, который постоянно вымогает у них деньги по СМС.

        HTTP 500, как известно, не баг, если его добились редактированием URL.

        Первым делом я нахожу что событие было (в логах, в базе где угодно), если следов нет, проблема не воспроизводится, код выглядит вменяемо, то её не починить, надо настраивать логгирование лучше.
          +14
          Угу. Юзеры они такие. Сами себе стреляют в ногу. Причем массово и локализовано во времени. Обычно они любят это делать сразу после выкатки на продакшн.
            +10
            HTTP 500 — баг всегда, ибо это Server Error.

            Если пользователь отредактировал URL, так как вам не надо — выдавайте HTTP 400 — Bad Request.
              0
              Для REST API — может быть, там нужно понять что запрос не нужно повторять. Для Web сайта — честно говоря никогда не видел чтобы с этим заморачивались, не видел поддержку во фреймворках. Не видел такого кода вообще.

              В принципе возврат HTTP 500 не нарушает HTTP спецификацию. Если появилось Exception — HTTP 500. Если будем делить exception на два класса — ожидаемые и не ожидаемые, мы потратим усилия, как при разработке API. Так же ухудшим безопасность.

              HTTP 500: The server encountered an unexpected condition which prevented it from fulfilling the request.

              HTTP 400: The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
                +6
                Из того, что многие делают криво и неправильно, не стоит делать вывод, что это хорошо.

                Проблема в том, что большинство разработчиков сайтов (и видимо даже фреймворков) никогда не читали стандарты на используемые ими протоколы. И это на самом деле очень печально!
                  –2
                  Это правильно для REST, если сделать так для Web, то куча случаев, когда баг на сервере (неправильно сгенерировалась HTML форма), будет выдавать HTTP 400 (т.к. эта же html форма неправильно послала данные). Множество реальных багов перейдут в разряд HTTP 400. + куча лишних усилий для рассматривание своих же внутренностей как API + ловля exceptions фреймворка и перевод некоторых из них в HTTP 400
                    +1
                    Это правильно для протокола HTTP
                    0
                    Ещё проблема, что HTTP 400 — «due to malformed syntax».
                    Это не всегда так. Например редактируем свойства объекта, который ещё не создался в базе. Синтаксис правильный — вернуть 400 — означающее «никогда больше не повторяйте запрос»? А когда объект создастся, запрос уже будет валиден.
                      0
                      Если это нормальная ситуация, например имеется очередь и пользователю не гарантируется немедленная реакция, то возвращать 200 и сообщение что попробуйте позже.

                      Если это race condition, то как раз в таких случаях правильно вернуть 500 и рассматривать именно как серверную ошибку, любые подобные рейсы требуют исправления.
                        0
                        Race или не race — это не известно. По легенде юзер отредактировал URL.

                        Так что известно только то что пришёл запрос редактирования объекта которого нет.
                        HTTP 200 с сообщением возвращать не нужно, т.к. по бизнеслогике такой ситуации быть не должно вообще, и она случается только если юзер отредактировал URL.

                        Тем не менее кто-то предлагает в этом случает вернуть HTTP 400, ссылаясь на HTTP спецификацию, а между тем HTTP 400 означает «due to malformed syntax», «The client SHOULD NOT repeat the request», так что возврат HTTP 400 в этом случае противоречит этой самой спецификации.
                          0
                          Ну а что значит неизвестно?

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

                          Если юзеру стал известен ID объекта, который физически не успел создаться и бизнес-логикой такого состояния не предусмотрено — то это рейс, который надо устранять.
                            +3
                            Так что известно только то что пришёл запрос редактирования объекта которого нет.

                            Для этого тоже есть код, HTTP 404 — Not Found

                            Тем не менее кто-то предлагает в этом случает вернуть HTTP 400, ссылаясь на HTTP спецификацию

                            Кто-то рекомендует её таки прочесть, и убедиться, что кодов таки немножечко больше, чем 200/400/500…
                              –3
                              Т.е. в одном и том же Web (не REST) приложении, при валидации данных, в сценарии что юзер редактировал URL, возвращать разные 40x коды?

                              Ну это же бред — ни кому не нужная работа, и ложные коды ошибок в случае реальных багов в приложении. Покажите хоть один сайт, который так делает?
                                +1
                                Т.е. в одном и том же Web (не REST) приложении

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

                                при валидации данных, в сценарии что юзер редактировал URL, возвращать разные 40x коды?

                                Ну вот смотрите, предположим у вас есть сайт, где можно посмотреть футболки. У футболки есть параметры, например цвет. Если кто-то укажет color=red, а у вас есть только зёлёные футболки, то это явный HTTP404 — Not Found, а если параметр цвета вообще не указали или указали неправильный цвет(color=зИлЁнЕнЬКаЯ), то это уже вполне себе некорректный запрос и HTTP400 — Bad Request.

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

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

                                Почему ложные? Они как раз очень точно описывают проблему!

                                Покажите хоть один сайт, который так делает?

                                Я уже говорил, что если все делают неправильно, то это не аргумент. В своих проектах я стараюсь такого не допускать и коллег учу тому же.
                                  +1
                                  Имхо, в примере с «color=зИлЁнЕнЬКаЯ», это все-же 404, а для 400й ошибки хорошо подойдет пример, когда какой-то параметр ожидается, а его нет.

                                  В качестве примера сайта для вашего оппонента подойдет любой сайт на Yii, там как раз сервер падает в 400 если какой-то экшн контроллера ждет параметр, а он не приходит.
                                    0
                                    Имхо, в примере с «color=зИлЁнЕнЬКаЯ», это все-же 404

                                    На самом деле это вопрос исключительно бизнес-логики.

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

                                    Либо сначала проверяем каталог существующих возможных значений цветов, и тогда, признав значение в принципе невалидным(то есть футболки такого цвета гарантированно существовать не может в нашей системе, а не закончились на складе, например), мы со спокойной совестью выдаём HTTP400.
                                      +1
                                      Ну… Вообще, между 404 и 400 в рамках HTTP есть существенное различие:
                                      400 — прямо указывает, что клиент не должен повторять запрос без модификаций
                                      404 — говорит что запрошен несуществующий ресурс, который может быть доступен в будущем. Т.о., при 404 клиент может повторить этот запрос без модификаций.

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

                                        А это не вам, как разработчику, решать — это вопрос бизнес-логики. Набор цветов вполне может быть каким-нибудь строго ограниченным.
                                          –2
                                          Зачем тратить строчки кода и тестов на выяснение есть ли такой цвет в принципе или нет, если в базе такого товара нет?

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


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

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

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

                                            А, разработчик да, конечно бизнес-логику он не описывает и тем более не диктует, но ведь и заголовки ответа к бизнес логике не имеют никакого отношения, разве не так?
                    +5
                    Правильный ответ сервера в случае некорректных аргументов в запросе клиента, когда сервер корректно обнаруживает и обрабатывает такую ситуацию — 4xx. Вот она как раз допустима при редактировании URL.

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

                    2. У саппорта может быть тикет и SLA. Чем не владелец/ответственный?

                    3. После того как фронтендщик, бэкэндщик и админ пошлют саппорта, по шапке получат все трое.
                    За доброту и умение работать в команде.

                    4. Не врет только наличие жалобы пользователя. У него действительно что-то случилось. А вот ее текст полон неправды.

                    5. В пятом пункте менеджер начинает принимать архитектурные решения?

                    Спасибо за пост, интересно.
                      0
                      1. Новичку-менеджеру надо обязательно с этого начать. А в дальнейшем, разумеется, выстраивать процесс.
                      2. См. п.1.
                      3. Плохой способ. Бить надо конкретного человека за его конкретный личный про… б. И то, аккуратно и нежно, иначе команду можно потерять.
                      4. Это правда. Я не совсем точно сформулирвал, спасибо!
                      5. Как крайняя мера — да, и только, если менеджер в прошлым очень сильный технарь. Иначе, сами понимаете, будет курам на смех и потеря полного авторитета в команде.

                      Не за что! Скоро сделаю еще один пост в эту же тему.
                        +1
                        среди менеджеров с техническим бэкграундом — 5% сильных технарей. И 95% менеджеров считают, что они входят в эти 5%.

                        Критическое свойство личности для менеджера — понимать, что ты не понимаешь, чтобы не делать false assumptions.
                      +6
                      Душевно написано :) У нас вместо «А, ну, это все база» чаще всего «А, ну, это все кэш» )
                        +5
                        А у нас 3 причины:
                        — кэш
                        — роботы
                        — у меня все работает!
                          +1
                          Разумеется. Код же он идеален и безглючен. Во всем и всегда виноваты внешние обстоятельства :)
                          +3
                          Насчет кэша — это отдельная песня. С одной стороны, если сапорт помог юзеру, предложив почистить кэш, это хорошо. А с другой стороны, проблема осталась у остальных 99%, которые в сапорт не писали, и решать ее надо все равно.
                            0
                            Был у меня, как у юзера, случай недавно. Платил карточкой на одном сайте, в итоге пустой экран. Деньги списались, но там где нужно, не появились, их просто нету. Вернутся через месяц, когда их банк разблокирует.

                            Пишу в саппорт — ответ, очистите кэш, попробуйте через 24 часа, лучше, в другом браузере. Ну спрашивается, у них что, даже деньги не логгируются вообще? Вернуть их ручками — не судьба?
                              0
                              Кеш – проблема плохого фронтенда. Лечится, в самом простом случае, тупо: в адреса файлов (обычно достаточно для js и css, но можно учесть и для картинок) добавляется номер релиза. Или номер пакета. Или хэш коммита. Конечно же, автоматически добавляется, а не руками каждый раз.

                              Тогда кеш будет продожать работать, но при обновлении браузер будет гарантированно брать новую версию файла.
                                0
                                Кеш не только на фронтенде есть. С фронтендом как раз проще всего, благодаря сказанному вами.
                                  0
                                  Если кеш не на фронтенде «залипает» когда не надо – то это откровенный баг разработки этого самого кеша :) И чистится он не пользователем, само собой.

                                  Ну и вообще, про фронтенд кеш в первую очередь подумал, т.к. сам фронтенд-разработчик.
                              +4
                              Если что-то тормозит — добавьте кеширование. Если что-то глючит — уберите кеширование.
                              0
                              Прежде всего, мы нашли владельца проблемы: это, собственно, ПМ.

                              В больших командах такое наверное не работает, но в маленьких, по моему опыту, если сразу не удаётся решить проблему, то дают её одному _программисту_, а он уже будет смотреть и фронтэнд и бэканд и базу и сервер.

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

                                  Заметим, кстати, что в больших компаниях часто бывает, что проект включает в себя 2-3 человека, но он, на самом деле, большой и ему нужен PM. Это бывает тогда когда проект соединяет в себя много других технологий, над которыми эти 2-3 не властны и которые недостаточно стабильны, чтобы можно было считать, что они просто работают всегда и везде (то, что любой разработчик пользуется OS в которой десятки миллионов строк не обозначает, что ему нужен личный PM).
                                    0
                                    Все именно так. Наличие неопределенности или неоднородности — это, само по себе, сигнал к тому, что проекту нужен PM.
                                  0
                                  Если баг был создан в баг-трекере, как он может зависнуть «ни на ком» или потеряться на стадии «а, ну это база» или «сделай логирование»? Это надо быть ну совсем уже потерянным менеджером, чтобы забывать о висящих багах насовсем (да и напоминалки от багтрекера для этих случаев есть).
                                    +1
                                    Он может зависнуть в вечной переписке туда-сюда. Это надо жестко пресекать. Для чего надо понимать цель каждой конкретной перестановки бага. Опять же, для начала надо это контролировать самому, а потом строить процесс и опираться на наиболее коммуникабельных технарей, которые могут самостятельно и обоснованно передавать другим проблему, без зависаний.
                                      +2
                                      Всё-равно не понимаю как такое может быть. Баг может быть перевешен с одного человека на другого только после того как первый доказал (логами, тестами, скриншотами) что это не его проблема и указал почему он считает (опять таки по логам, тестам, скриншотам) что это проблема другого человека. Это не «вечная переписка», это движение вперёд. Оно может войти во второй круг только с комментарием «твои логи\тесты лажа, потому что вот в них баг, исправь и проверь снова» — но это тоже не вечный цикл, а прогресс.
                                        0
                                        «может быть перевешен» — на самом деле, все может быть. Люди часто ошибаются. Причем, чаще ошибаются так, что ложно считают, что проблема не на их стороне, чем наоборот (это, скорее, свойство человеческой психики, оставаться в зоне комфорта как можно дольше).
                                        Движение вперед может быть без менеджера только если он настроил процесс, ввел формальные правила etc. На первой же стадии, когда менеджер только взял проект, еще ничего не настроено, и сюрпризы, в т.ч. такие, как я описал в статье, подстерегают за каждым углом.
                                          0
                                          Это вы каких-то сферических разработчиков в вакууме рассматриваете. На практике зачастую достаточно написать пару строк (что-то типа «информации мало, в наших палестинах оно не воспроизводится, скорее всего это BLODA), поставить приоритет P3 и всё — баг будет висеть годами.
                                            0
                                            Для таких, конечно, нужен вышеуказанный менеджер с кнутом. А для нормальных после стадии «информации мало» идёт запрос на дополнительную информацию, логи, дампы, доступ к машине, где воспроизводится и т.д. До победного финиша. А у Вас получается, что люди сами себе на плечи вешают груз, который никогда не будет снят и провоцируют менедежра надавать себе по шапке. Прямо какие-то мазохисты.
                                              0
                                              Как я описал в статье, иногда роль PM на себя берет один из разработчиков. Обычно это человек с высокими коммуникативными навыками, с широким представлением о технологиях и с сильным продуктовым видением. Давайте скажем прямо: не все технические специалисты обладают этими навыками, да и не всем это нужно, от разработчика требуется в первую очередь быть суперпрофи в своей конкретной области, уметь выбирать правильную архитектуру, и быстро и безбажно разрабатывать.
                                                +3
                                                Звучит это так: «в основном приходится работать с безответственными асоциальными мудаками, которым наплевать на продукт, работодателя и друг друга. Но иногда среди них находится один нормальный, который...»
                                                  +1
                                                  Хорошему менеджеру для запуска проекта/продукта надо самую малость — некоторое количество сильных технических спецов. Все остальное — сильное продуктовое видение, коммуникативные/социальные навыки, ясное представление о текущем статусе работ и об остаточных работах до завершения проекта, командный дух, ответственность за весь проект/продукт целиком и полностью — он родит внутри себя.
                                                  Плохой менеджер будет ждать всего того, что он сам обязан делать, от своей команды, которая и без того сильно погружена в технические детали, архитектуру, разработку. И в итоге, обозвав их всех теми словами, которые вы написали выше, успешно провалит проект, напрасно потратив свое время, время своих спецов и деньги компании.
                                                0
                                                А для нормальных после стадии «информации мало» идёт запрос на дополнительную информацию, логи, дампы, доступ к машине, где воспроизводится и т.д. До победного финиша.
                                                Господи. Такое ощущение, что вы никогда не сталкивались с крупными проектами. Давайте рассмотрим практический пример. Возьмем, к примеру, Chrome с его почти миллиардом пользователей. Сколько у него разработчиков? Ну пусть тысяча (учитывать волонтёров, которые иногда пару патчей не будем). То есть на одного разработчика приходится 1000000 пользователей. Напишу прописью: один миллион пользователей на одного разработчика. И они файлят баги… ну скажем по одной штуке раз в два-три дня в пересчёте на одного разработчика. Ну и? Сколько у вас должно быть рабочих часов в дне, чтобы с каждым багом разбираться «до победного финиша»? 24 часа или 240 часов? Как вы это себе вообще представляете?
                                                  0
                                                  Чем в этой ситуации поможет менеджер? Развернёт время вспять?
                                                    0
                                                    Так сколько говорите у chrome багов всего? По три тысячи новых багов каждые 2-3 дня? И все уникальные и действительно баги?

                                                    Кстати если действительно chrome такое г*, то юзеры перестанут файлить мелкие баги, будут только серьёзные, значит процент дубликатов увеличится.
                                            +1
                                            Если ситуация диагностируема и воспроизводима — это, разумеется, стандартный случай, не требующий вмешательства менеджера.

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

                                            Маленький сервис такую проблему может в принципе никогда не поймать проблему или забить на нее, т.к. пострадавших пользователей единицы. Крупный сервис не может себе позволить забивать ни на какую проблему, т.к. на нескольких миллионах юзеров и тысячах серверов любая редкая конфигурация или сбой обязательно повторятся. 0.01% в наших масштабах это несколько тысяч пострадавших, из которых в поддержку обратятся 5-10 человек, и вдвое больше начнут жаловаться в бложиках и на хабре.
                                              +1
                                              По моему, как раз процент юзеров, на которых можно «забить» у всех стабилен :)
                                                0
                                                Ну почему же. Даже если проблема не решается со стороны сервера и есть подозрение на работу клиентского софта — в поддержке mail.ru есть выделенная группа, которая будет разбираться с подземным стуком у юзера вплоть до подключения к нему тимвьювером, если он к этому готов. И таким образом тоже отлавливались достаточно интересные проблемы. Но, естественно, для того чтобы «попасть» на такую поддержку надо очень четко описать симптомы «стука» и пройти через стандартные рекомендации типа очистки кэша.
                                                  0
                                                  Крупный сервис не может себе позволить забивать ни на какую проблему, т.к. на нескольких миллионах юзеров

                                                  Мой коммент относился к этой, общей фразе. По моему опыту одинаково забьют и на 1 юзера и на 10,000, если это 0.1%, а может даже 1% (зависит от того, на сколько компания не тенят на корпорацию добра).

                                                  Конкретно про mail.ru — ничего не могу сказать — давно не пользуюсь, баги не репортил. Хотя очень сомневаюсь что у вас 0 технического долга. Это была бы прямо уникальная компания.

                                                  Баг фиксите только с очень высоким приоритетом, который затронул 1 юзера? Или любой баг, затронувший одного юзера, когда-либо фиксится, не зависимо от серьёзности (т.е. все тикеты когда-либо «всплывают» в очереди тикетов)?
                                                    0
                                                    Проблема, имеющая место быть хотя бы у двух юзеров по моим личным критериям считается массовой, и мы начинаем ее исследование и решение с блокирующим приоритетом. Если таких проблем, вдруг, становится много параллельно, то мы запускаем, опять же параллельно моделированию и фиксу проблем, внутренний процесс проверки технологий разработки, проверки качества тестирования, с целью найти возможную общую базу появления сразу нескольких массовых проблем.
                                            +3
                                            >> сервис не смог сходить в какую-то базу или в другой сервис
                                            позабавила фраза.

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

                                            Менеджер не нужен. И тем более менеджер-герой-технарь, способный силой мысли двигать горы, просто настройте процессы
                                              +4
                                              1. Вы сами хотя бы раз были в роли менеджера проектов?
                                              2. «Менеджер не нужен» и «просто настройте процессы» в одном предложении улыбнуло. Статья как раз для менеджеров, т.е. для тех кто настраивает процессы. Для вас, видимо, откровение, что процессы настраивает конкретный человек, а не господь бог?
                                                0
                                                >> 1. Вы сами хотя бы раз были в роли менеджера проектов?
                                                ответ из разряда «А чего добился ты?»

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

                                                    «пипл ответственненный за качество проблему воспроизводит» — а если не воспроизводится, то ваши пользователи все это время будут страдать?

                                                    «баг на разработчика» — а если разработчик не один, то как выбрать?

                                                    Ну и тд
                                                      0
                                                      видимо, вы меня не поняли. попробую отвечать вопросом на вопрос:

                                                      А если багрепортов сотни, Вы тоже каждую проблему будете решать лично?
                                                        +2
                                                        Смотря, про какую ситуацию вы говорите. Если про мою текущую деятельность, то у меня команда из почти 100 человек, они все суперпрофессионалы, зоны ответственности достаточно четко поделены, внутри ест иерархия, процесс налажен, и я лично очень редко вмешиваюсь в решение проблем (но вмешиваюсь иногда, держу руку на пульсе, понимаю, по результатам, где плохо устроен процесс, когда проблемы решаются не достаточно оперативно, обсуждаю это с командой, делаю выводы, принимаю решения).

                                                        Если же речь про другую ситуацию, в которых я, разумеется, побывал, на новом проекте или в новой компании, то, да, для начала надо решать руководить решением лично. Только так вы сможете, так сказать, с земли, начать строить процесс, направленный на минимизацию вашего участия и вместе с тем увеличения качества продуктов (в сутках всего 24 часа, один человек все сам сделать не может).
                                                +3
                                                Даже если проблема воспроизводима, то вот в этот момент:

                                                " тим лид или тех лид ассайнит баг на разработчика"

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

                                                Проблема может быть еще и невоспроизводимой в тестовых условиях. Например, по результатам разбирательств иногда выясняется, что проблема есть у пользователей зарегистрировавшихся более 7 лет назад, когда были другие требования к формату какого-либо поля, и есть символы которые невозможно получить в этом поле в текущей версии продукта.
                                              • UFO just landed and posted this here
                                                  +1
                                                  Какие-то инертные разработчики. Если такая ситуация с ними, то это проблема подбора команды. Задача менеджера — создать команду, организующую себя изнутри предельно самостоятельно.
                                                    +2
                                                    Абсолютно. Но пока создаешь команду, надо помнить, что есть пользователи, которые приносят твоей компании деньги, и из которых ты получаешь зарплату, а поэтому хочешь-не-хочешь, но проблемы надо уметь решать в любой ситуации. И, да, даже при самой лучшей команде, поверьте, бывают различные казусы и не желание взять на себя ответственность за решение проблемы у разных ее членов. Если бы все разработчики всегда сами организовывались самостоятельно, то менеджеры были бы не нужны.
                                                    +2
                                                    > Существует расхожее мнение, что проблемы решают исполнители, а управленцы только ходят и мешают.

                                                    Это благодаря бездарным менеджерам, которых, к сожалению, большинство. Я видел и плохих и хороших, поэтому могу сказать, что иногда от плохих столько негатива… что хочется всех кто назовет себя менеджером к стенке поставить. Потом отпускает =).
                                                      0
                                                      Бездарных менеджеров много, это правда.

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

                                                      Хороший менеджер что-то всегда привнесет в процесс, создает добавленную стоимость. Свои технические навыки (давая советы, ускоряющие решение проблемы), или свои организационные навыки (например, сбор брейнштормов из всех необходимых спецов для решения проблемы), или лидерские качества (мотивируя команду на решения проблемы и ведя ее за собой), или свои управленческие качества (четко отслеживая статусы решения проблемы, не давая проблеме «закиснуть» или уйти в «футбол»).
                                                      0
                                                      Не уверен, что решение перечисленных проблем — это именно обязанности прожект-менеджера (ПМ). Здесь всё-таки речь идет о проблеме взаимодействия между 2-3 небольшими группами разработчиков + ИТ. И если мы говорим о более полной иерархии: ПМ -> TM -> Dev/QA/Support Lead, то обычно такие задачи просто созданы для решения ТМ-ами или даже лидами конкретных групп. Это ТМ (или лид) должен видеть, что в его команде есть проблемы взаимодействия, и если такие проблемы мешают закрытию внешнего дефекта, именно он должен это взаимодействие наладить и помочь коллегам решить такой, сугубо внутренний, вопрос.

                                                      Как уже говорили выше, ПМ прежде всего двигает весь проект к светлому будущему, и он уже должен решать более глобальные проблемы: например, почему в одном из стримов разработки так много незакрытых дефектов высокого приоритета. И тогда он придет к соответствующему ТМ-у этого стрима и спросит: «доколе?». И вряд ли тут ПМ-а будет интересовать ответ, если ТМ ему скажет, что мол у него 2 разработчика встали в позу и уже неделю не хотят фиксить один из 100 дефектов.

                                                      Все, конечно, зависит от конкретного проекта: есть проекты и по 5, 10, 15 человек, где ПМ по сути может быть и ТМ-ом, и Dev Lead-ом. Но если проект большой и ТМ-ы справляются с работой, то ПМ-у вряд ли стоит отвлекаться на подобного рода проблемы.
                                                        +1
                                                        Вы описали сейчас интересную ситуацию. Я про нее тоже напишу в следующих статьях. Ситуация называется: я управляю проектом/продуктом, имея в прямом или продуктовом подчинении не конечных исполнителей (разработчики, тестировщики, админы etc), а руководителей. Это, разумеется, более сложная ситуация. И, да, если ваш TM рассказывает вам про свои проблемы, вместо того, чтобы решать их, то у перед вами сложный выбор: либо коучить его (трата времени, которого и так мало), либо уволить его (трата времени на поиск нового TM + врубания его в суть дела).
                                                        В чем тут основное отличие от руководства конечными исполнителями? В том, что из-за взрывного роста IT за последние годы, есть огромная нехватка управленцев. Фактически, большинство управленцев в IT — люди с очень небольшим опытом в управлении (1-2 года). И, разумеется, даже если человек был суперзубром в C++ или Perl, с опытом в 10 лет, то это абсолютно не говорит о том, что он сразу же будет хорошим управленцем. Поэтому, когда под вами управленец, то он, возможно, еще учится, и вам его зачастую надо коучить (даже если вы сами новичок на вашей текущей позиции).
                                                          0
                                                          Да, все верно — нехватка менеджеров (как ПМ, так и ТМ) ощущается очень остро. Не говоря уж о нехватке хороших, качественных менеджеров. Наверное, всё потому, что вырастить такого менеджера, не дав понюхать ему пороха на реальных задачах и проектах, по сути нереально.

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

                                                          Интересно было бы ознакомиться с опытом «взращивания» менеджеров, в реальности.
                                                            0
                                                            К сожалению, есть такие технические детали (особенно на стыке команд), о которых, если менеджер не подумает, то никто не подумает
                                                        0
                                                        По одному из ваших же правил получается, что менеджер борется лишь с симптомами и не устраняет проблему: над проектом работают безответственные му… ки, из которых не нашлось никого, ощущающего ответственность за качество продукта. Тогда менеджер нужен, чтобы ходить, пинать, упрашивать, разбираться, угрожать, заставлять и т.д.
                                                          0
                                                          Неверная интерпретация
                                                            0
                                                            Может быть, но в хорошо построенном процессе за описанные действия отвечают совсем другие люди — лидеры команд, тестировщики, вся команда, ответственные за саппорт и т.д. Если менеджер занялся такими делами, то остальным плевать.
                                                              0
                                                              В идеальном мире да. А в реальном мире за проблемы стыке команд приходится отвечать менеджеру.
                                                          0
                                                          PM не должен ходить к простым разработчикам!
                                                          Это главное правило всеобщего спокойствия и менеджера в частности!

                                                          PM — работает только с тим-лидом.
                                                          Задача менеджера объяснить тим-лиду в чем дело(ex. перевести письмо от саппорта в тему 500-ой ошибки).

                                                          Дальше работает тим-лид. Почти все пункты, которые Вы описали выполняет тим-лид. Если нет, то роль тим-лида выполняет PM и это плохо, ибо уровень экспертизы PM априори низкий (в лучшем случае это джуниор, который думает, что знает как надо писать софт ).
                                                            0
                                                            Тим-лид какого тима?
                                                            +1
                                                            Из 3 компаний где я работал с менеджерами ИТ продуктов НИКТО из них не был специалистом в этой области, хотя бы поверхостно. В итоге так и получалось что писали пачки задач, потом переделывали все, перед релизом еще раз все меняли да так что после релиза разработчики уже были выжатые как лимоны. Баги исправлялись намного хуже чем должны были, понимаю почему все стараются переложить их друг на друга.

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

                                                            Only users with full accounts can post comments. Log in, please.