Pull to refresh

Comments 84

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

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

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

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

Если пользователь отредактировал URL, так как вам не надо — выдавайте HTTP 400 — Bad Request.
Для 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.
Из того, что многие делают криво и неправильно, не стоит делать вывод, что это хорошо.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

Не за что! Скоро сделаю еще один пост в эту же тему.
UFO just landed and posted this here
Душевно написано :) У нас вместо «А, ну, это все база» чаще всего «А, ну, это все кэш» )
А у нас 3 причины:
— кэш
— роботы
— у меня все работает!
Разумеется. Код же он идеален и безглючен. Во всем и всегда виноваты внешние обстоятельства :)
Насчет кэша — это отдельная песня. С одной стороны, если сапорт помог юзеру, предложив почистить кэш, это хорошо. А с другой стороны, проблема осталась у остальных 99%, которые в сапорт не писали, и решать ее надо все равно.
Был у меня, как у юзера, случай недавно. Платил карточкой на одном сайте, в итоге пустой экран. Деньги списались, но там где нужно, не появились, их просто нету. Вернутся через месяц, когда их банк разблокирует.

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

Тогда кеш будет продожать работать, но при обновлении браузер будет гарантированно брать новую версию файла.
UFO just landed and posted this here
Если кеш не на фронтенде «залипает» когда не надо – то это откровенный баг разработки этого самого кеша :) И чистится он не пользователем, само собой.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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