Техническая ипотека: что и кому должен тимлид

    Всем привет! Меня зовут Александр Афенов. Я тимлид команды разработки Order Processing в компании Lamoda. В прошлом году я выступал на TeamLead Conf 2018. Запись выступления доступна по ссылке.

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

    image

    Доклад будет разбит на 3 части:

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


    Lamoda как IT-компания


    Lamoda в первую очередь известна как крупный ритейлер модной одежды, обуви и аксессуаров в России и СНГ. При этом мало кто знает, что за процент или фиксированную сумму мы оказываем услуги разным бизнесам / юридическим лицам.

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

    Lamoda может решить подобные проблемы следующими способами:

    1. Предоставить услуги своей службы доставки.

      LM Express — это наша собственная служба доставки, которую мы давно развиваем и самостоятельно автоматизируем.
    2. Обеспечить коммуникацию с клиентом. Для этого у нас есть свой колл-центр.
    3. Хранить товар у себя или даже продавать его за вас (комиссия).
    4. Marketplace. Товары партнёров могут отображаться в нашем мобильном приложении, на сайте или его мобильной версии, а всё остальное партнёры делают сами.

    Возникает вопрос: “Как успеть решить и свои задачи, и удовлетворить потребности партнёров?” У нас есть меняющийся и развивающийся бизнес со своими потребностями. Мы каким-то образом все улучшаем, развиваем и двигаем вперед. При этом еще нужно соответствовать тем хотелкам, которые приходят извне. Кажется, что для этого нужно своё IT, и не маленькое.

    Именно об in-house разработке мы и говорим на всех конференциях с 2016 года. Все процессы мы автоматизируем сами. Это около сотни различных сервисов: от обработки заказов и платежей до работы с адресными объектами и гифт-сертификатами. Поддержкой всего этого занимается команда из приблизительно 300 человек.

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

    Ключевые вопросы


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

    Корпоратив в Lamoda — это тематический праздник, к которому все любят готовиться. Поэтому в день X архитектор моего отдела пришел на работу при параде, во фраке. На тот момент наша команда занималась сервисом обработки заказов. Это был монолит на старом фрэймворке Zend1. Что я наблюдал? Ребята подготовили вынужденный релиз и что-то захотфиксили. Удостоверившись, что всё ок, собрались и поехали на праздник.

    И вот я сижу. Релиз уехал в продакшн с хотфиксом, а передо мной красивый телевизор на 50 дюймов, на котором какой-то дашборд. На дашборде был график с надписью «Rabbit MQ problems». Кажется, что если на нем есть какие-то данные, значит, что-то сломалось. Но я не знаю, куда мне посмотреть чтобы проверить эту гипотезу.

    Наверное, можно глянуть в какие-то логи. Однако я только третий день на работе и не знаю, где они. Наверное, я могу найти ссылку на grafana-борду. Быть может стоит посмотреть через нее источник метрик и покопаться там? Да, но это слишком тернистый путь. Я бы хотел, чтобы это было как-то задокументировано. И опять же есть вопрос: кто все эти люди, которые сидят вокруг? Два или три этажа, по которым распределено IT. Все что-то делают, и я не знаю, с кем мне коммуницировать, если что-то пошло не так. Нет сводной таблицы, понятной, к кому я мог бы обратиться, если понял, что релиз сломался. А может есть дежурный, а я просто не в курсе?
    *(конечно же он был)*

    Были и другие вопросы. Первый и самый смешной, к которому мы будем неоднократно возвращаться: “Где документация?”. Ответ прост: одновременно везде, нигде и в головах опытных сотрудников. Так как все уехали на корпоратив, а о том, где лежат доки я не знаю, то для меня ответ звучал как “нигде”. У меня был readme по которому я раскатывал проект у себя на ноутбуке. Но этого было недостаточно. Хотелось получить ответы и на многие другие вопросы. Например, какие основные правила “поведения” для разработчика?

    Поясню: я решил запросить доступ к боевой системе, чтобы зайти в пользовательский интерфейс. Для меня это было бы очень полезно, так как моя задача на испытательный срок была про переработку системы авторизации, и хотелось потыкать кнопочки, авторизоваться на production стенде. Я кинул заявку в службу безопасности, на которую быстро получил лаконичный ответ: “Не-а, доступ не дадим”. Оказалось, что доступ в боевую систему получают только ее реальные пользователи: работники склада, колл-центра и так далее. Так как я до этого работал в телекоме, то привык, что у меня был доступ на чтение и запись в production базы разных сотовых операторов. А тут, оказывается, так нельзя. Есть протокол.

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

    Следующие интересующие меня вопросы касаются дальней перспективы. Например, как и куда расти?

    Почему это важно? Потому что уже со старта мне нужно как-то себя вести. Я пришел на должность middle php developer. Что мне делать дальше, чтобы превосходить ожидания, и в дальнейшем получить более высокий грейд, например Senior? И еще один вопрос: “Чего от меня ждут на моем текущем грейде?” То есть насколько я должен быть вовлечен в такие процессы, как code review, релизы, дежурства?

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

    Performance review


    Каждые 6 месяцев человек проводит так называемое self review. Он рассказывает о крутых штуках, которые успел сделать за отведенное время. Однако тут есть подводный камень. Связан он с тем, что люди обычно указывают те достижения на self-review, которые они субъективно склонны таковыми считать. Думать в терминах бизнеса непривычно, и даже если рутинный проект позволил заработать компании кучу денег, то для разработчика он мог не представлять вызова или интереса. Есть опасность, что в таком review этот проект не будет указан.

    Следующий этап — это оценка от коллег (peer review). Затем следует серия комиссий, на которых идет общение между тимлидами, руковолителями отделов, СТО, и, если нужно, HR-директором. Потом сообщение о результатах.

    Какие возможны исходы?

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

    Другой вариант – это двойка. Кажется, чего-то не хватило. Может быть скорости, предсказуемости, упорства. Что-то необходимо улучшить.

    Тройка – чего ожидали, то и получили. Человек работает в адекватном темпе и во всех отношениях соответствует своему грейду.

    Четверка – сделал больше, чем договаривались. Кандидат на повышение должности/оклада.

    Пятерка – шерстяной волчара. Кажется, что пора повышать, давать премии и так далее.

    Я прошел сам через несколько итераций такого review. Раньше оно проводилось каждый квартал, что было не очень удобно, так как за 3 месяца не всегда случается возможность проявить себя. Сейчас review происходит раз в полгода.

    Таким образом, сначала я из middle developer вырос в senior. Потом мой тимлид решил, что теперь больше хочет работать с техникой и перешел на позицию техлида (архитектора), а я стал тимлидом.

    И что дальше? Мне нужно что-то делать, как-то осваиваться.

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

    Еще один момент – это те же “основные правила”. Что я могу?

    Наверное, я могу следить за выполнением задач, делать code review. Возможно, у меня теперь есть власть менять процессы, как-то по-своему коммуницировать с людьми.

    Как и куда расти? Этот вопрос никуда не девается, потому что потом вы можете захотеть стать руководителем отдела (group lead).

    Ну и вопрос – чего от меня ждут, тоже мне кажется вполне понятным.

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

    Что должен тимлид?


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

    Разумеется нужно тушить code review, когда в ходе него возникают конфликты. Мониторить, что происходит, двигать задачи по статусам. Также я на регулярной основе выполняю обязанности релиз-инженера. Необходимо часто думать о том, каким образом наш деплой аффектит всех остальных.Сервис, которым я занимаюсь – это order processing. Он связан примерно со всеми системами Lamoda и, соответственно, способен затронуть при своем релизе множество бизнес-процессов.

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

    Ещё нужно уделять внимание коммуникациям. Сюда относятся personal meetings, которые проходят примерно раз в две недели с каждым разработчиком; ретроспективы, планирование, коммуникации с менеджерами и другими отделами. А ведь ещё неплохо бы не протухнуть.

    Многие говорят, что было бы здорово после 10 лет разработки получить соотношение “менеджмент к разработке” в районе 80 к 20. Даже это не всегда достижимо. В итоге, вы неизбежно теряете экспертизу и выпадаете из текущих трендов. Необходимо продолжать расти дальше.

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

    Ротация ролей


    Введу в курс дела тех, кто не знает, и расскажу, что такое bus factor.

    Bus factor — это число, которое говорит о том, что если определенное количество разработчиков “собьет автобус”, то работа над проектом встанет. Он может проявляться на самых разных уровнях. Например, это может быть bus factor по какому-то конкретному сложному элементу системы.

    Допустим, у нас есть кейс, в котором нужно разгрести некую систему отчетов. Разработчик потратил 5 дней на то, чтобы это сделать. Баг был сложный, но его исправили, и все стало хорошо. Потом возникает еще какая-то проблема в этом же модуле, а тот самый разработчик оказывается на больничном. Это значит, что следующий человек должен потратить столько же времени на то, чтобы разобраться в проблеме. Разбираться придется с нуля, потому что документации (ха-ха) нет.

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

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

    Саппорт-инженер


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

    Кто такой саппорт инженер?

    У нас это парень, который разбирает саппортный бэклог. Он пришел на работу, у него нет ни единой задачи. Он открыл бэклог по поддержке в таск-треккере (Jira), а там задачки отсортированные по критичности. Взял самое важное и начинает чинить. После того, как все проблемы решены, записывает, почему оно сломалось и как избежать этого в будущем. Если у него нет другого саппорта (это забавно, потому что саппорт не кончается никогда), то он смотрит в технический бэклог, который и так достаточно большой.

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

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

    Релиз-инженер


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

    Бывает так, что нам нужна коммуникация с другими командами перед деплоем, чтобы предупредить их об изменениях. По итогу, релиз-инженер все выкатывает и смотрит, не разнесло ли чего. Мы используем для этого, Sentry, Prometheus, Icinga, смотрим в Elastic, при помощи Kibana. Релиз-инженер принимает решение, что делать, если что-то пошло не так. То есть именно в его ответственность входит решить, нужен ли какой-то hotfix, или мы все сломали, теряем деньги и нужно делать откат. Решение об откате принимаем только в крайнем случае, но и такое бывает.

    Он же (релиз-инженер) записывает возникающие проблемы. Если что-то разорвало, было бы здорово учиться на своих ошибках. Для этого он указывает дату релиза и ошибки, которые привели к проблеме. Это дает возможность следующему релиз-инженеру посмотреть на типовые проблемы и избежать их. Ну и да, он не занимается этим дольше недели подряд, потому что собирать релиз – это дорого.

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

    Техлид


    Другая более интересная виртуальная позиция – это технический лидер.

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

    Выводы


    Что мы получаем в итоге?

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

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

    С этого момента тимлиду можно и нужно делегировать свои задачи подчиненным, потому что, если вы помните, у тимлида есть задача самому не протухнуть и куда-то расти.

    Благодаря таким практикам появляется возможность наконец-то отдать кому-то часть своей работы. Например, релизы. Это 4-8 часов в неделю, которые внезапно освобождаются время от времени. Теперь вы можете потратить их на разработку, чтение статей, решение других задач. Большой ошибкой будет не забукать это в календаре и потратить на не самые полезные встречи. Хотя, как правило, так и происходит :) Теперь тимлид может радоваться, так как у него появилась возможность меньше нервничать и доверять своим сотрудникам часть своей работы. Если с ним самим что-то случится, то проекты не встанут.

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

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

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

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

    В итоге, все сводится к одной весьма конкретной цитате: «Задача лидера в том, чтобы было больше лидеров, а не тех, кто слепо следуют за лидером”. Я считаю, что использование этих инструментов поможет вам вырастить для себя, на минуточку, команду тимлидов. Это позволит вам двигаться дальше в профессиональном и карьерном плане. Компании, команде и проекту это даст возможность комфортно существовать. Ещё вы наконец-то сможете спокойно сходить в отпуск.
    Lamoda
    81,78
    Russian Fashion Tech
    Поделиться публикацией

    Комментарии 15

      +8
      Performance review

      Мне 45 лет и я алкоголик ни разу не видел обьективного ревью.
      Либо тебе с барского плеча кидают хорошую оценку даже не глядя на достижения, либо тебя посчитают «по процессам», но никогда оценка не была по настоящему обьективной. Возможно идея ревью не так и плоха, но все обычно упирается в конкретные персоналии а это недопустимо особенно при процессном подходе.
      Короче нет обьективной системы оценки.
        0
        Идеальной точно нет, но что мешает стремиться? Нужно четко формулировать критерии оценки. Например: «если ты делаешь только поставленные задачи и не проявляешь никакой инициативы, то скорее всего это тройка».
        Ещё неплохим критерием является ценность проделанной работы для бизнеса. От этого критерия веет холодом, но бывают кейсы вида «разработчик принес по собственной инициативе code fixer, что ускорило процесс ревью и уменьшило время за которое фичи попадают в production». Никто не будет считать это в рублях, но профит очевиден, это будет отмечено и учтено в оценке.
          +6
          Нужно четко формулировать критерии оценки.

          В этом и проблема.
          Не получается эти цели формулировать четко.
          Ценность проделаной работы в разработке вообще не прослеживается из за временного лага.
          Ты придумал телефон, и пока он вернется прибылью пройдут годы.
          Потому и пишут всякую абстрактную фигню вроде ценностей компании.
          Лет 20 назад работал в большой финской компании.
          Команда — 15 человек разработчиков. Сверху спустили таргеты для перфоманса.
          Самый главный — следовать глобальным КПИ компании с весом 75%.
          Самый главный из КПИ — кастомер сатисфакшен. Сатисфекшен считался по нескольким параметрам.
          Самый первый — мы должны были ответить на запрос о квотации в течении 2-х суток.
          Потом уже таргеты по работе в проекте, но это если клиент согласится с ценой.
          Наш менеджер придумал заряжать в квотейшен цену раз в 5-10 выше рынка, чтобы клиент увидел, офигел и ушел прочь.
          Зато таргет выполняется идеально, отвечаем на запросы быстро — таргет = 100%.
          Прошел год — мы сделали ноль проектов, зато все получили неслабую премию по результатам перфоманса.
          5 лет спустя компания обанкротилась.
            0
            Невыполнимые в полной мере цели вида «достичь таких-то показателей» — это в нашем случае обкатываемая сейчас модель OKR, и она на performance review не влияет. Она призвана направить множество людей / отделов / департаментов / всю компанию к общей цели, и тут ещё, пожалуй, предстоит проделать кучу работы.

            Я верю в то, что человек может достигать хороших оценок даже не думая о всех этих 360 review, комиссиях, шкалах и «выполненных договорённостях», если у него есть цель и мотив для того чтобы не просто жать кнопки, но заботиться о результате своей работы. У кого-то есть врождённая усидчивость, внимательность, перфекционизм и прочие качества, что помогают с первого захода делать задачи самой разной сложности, попадать в эстимэйты, и это не остаётся незамеченным на ревью.
            А у кого-то по-другому горят глаза, хочется всё починить, притащить в легаси систему удачный и подходящий паттерн проектирования, сделать более информативные мониторинги, забороть root cause типового саппорта, автоматизировать рутину, сделать бота оповещающего команду через телегу о зависших в code review реквестах. Такое проявление у нас действительно фигурирует в «фигне вроде ценностей компании» и мы зовём это ownership. Только мы не делаем из этого культ или мантру и не обмазываемся красивыми словами, а пробуем разные подходы для развития в людях таких качеств. Как раз дежурства и техлидство небольших проектов помогают лучше всего, так как «включается» ответственность за систему и появляется более глубокое понимание возможных последствий собственных решений. Полезна любая деятельность выходящая за рамки механического выполнения тикетов.

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

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

              Потому что это может, например, может быть результатом провала команды маркетологов или ошибкой менджмента.
              У меня бывало такое не раз, делаешь что то крутое, чего маркетологи и менеджеры не видят потенциала и спускают это на тормозах.
              Потом бац — у конкурентов то же самое — взлетело.
              С моей точки зрения, с точки зрения разраба, перфоманс адекватно оценить невозможно.
              Взлетит разработка или нет — зависит от массы случайностей, которыми я не управляю, я выложился на 146% и сделал что мог.
              Вот прямо сейчас я в процессе такого бодания, я предложил отличный концепт тестовой системы, который никто кроме меня не понял, большинству элементарно не хватило знаний и опта в этой области.
              Решением большинства мой концепт отклонили а мне сказали что я (1) занимаюсь херней.
              В результате систему построили по другому концепту, система работает плохо, медленно, с ошибками, поскольку я ее разрабатывал — все опять недовольны, (2) ты опять занимаешьша херней.
              Когда начали приходить жалобы на наш продукт, который вышел из строя, (тестовая система пропустила брак), мне сказали что ты (3) просто криворукий лох.
              Слава Богу на разборе полетов где были уже наши технические спецы, они легко разобрались в чем косяк, раскритикоквали текущий концепт и одобрили мою идею.
              Но и здесь, решением большинства было принято что я вношу исправления в неработоспособный концепт доводя его до состояния кое-как работающего и только потом начинаю делать свой. Кто знает как сложно доводить чужой да к тому же и неработающий концепт поймет этот крик души.
              В результате на этапах 1,2 и 3 я был выставлен полным лохом, но худшее начинается сейчас.
              Сейчас я уже виноват в том что выставил в невыгодном свете всех остальных и все посылают мне лучики ненависти.
              Угадайте, какой будет мой перфоманс?
              Смысл написанного — простой пример систематически неверной оценки.
            0
            Никто не будет считать это в рублях, но профит очевиден, это будет отмечено и учтено в оценке.
            Это может быть очевидно технарям, но вовсе не очевидно менеджерам. Именно от них будет зависеть финальная оценка, а отзыв будет в духе «занимался фигнёй две недели» (условно конечно же).

            Всё упирается в человеческий фактор. В идеальной системе с идеальными личностями всё будет хорошо. Но никто не идеален, и тут уже становится вовсе не факт, что заметят, либо если заметят, оценят, если оценят, то адекватно, и так далее. А ещё могут быть интриги вида: «что-то я не справляюсь, свалю всё на коллегу, скажу что плохо работал». И такие примеры есть в крупных известных компаниях.
          +3
          Тройка – чего ожидали, то и получили. Человек работает в адекватном темпе и во всех отношениях соответствует своему грейду.
          Четверка – сделал больше, чем договаривались. Кандидат на повышение должности/оклада.

          А тем временем «Тройка» посмотрел на выросшие по рынку зарплаты и решил уволиться,
          да и «Четверка» хочет повышение, а не быть только кандидатом…
          • НЛО прилетело и опубликовало эту надпись здесь
              0
              Тройка порою даёт и другой эффект: «а как я могу получить оценку выше или промоушен». Это вопрос специфики человека и хорошая задача для руководителя. Ещё можно оперировать зарплатной вилкой в рамках грейда.
              0
              Интересная статья, спасибо!
              У нас в компании так же существует виртуальная роль релиз-инженера, причем по штуке в каждой команде. Только техлид у нас один на каждый проект, да и саппорт-бэклог распределяется по релизам и размазывается по всем разработчикам, а то получится, что одни только творят, а другим еще и чинить приходится :)
                0
                Ну чинить приходится по очереди всем, в этом суть задумки, а техлид в команде тоже один, и он отвечает в полной мере за состояние и развитие всех подконтрольных команде систем. А «временные» техлиды тащат конкретные технические или бизнесовые проекты и принимают решение в их рамках. По мере роста и накопления опыта задачи становятся крупнее и сложнее, в некоторых командах техлид/тимлид в итоге перестают быть одним человеком и разделяются на архитектора и people-менеджера.
                Если коротко, то перекосов стараемся избегать, у нас нет тех, кто всю дорогу тащит саппорт или только дизайнит новое.
                0
                Хорошая статья, и многие вещи, особенно ротация ролей в команде отлично знакомы и работают на ура. Я бы еще добавил роль скрам мастера, который каждую неделю ведет ретро, демо и груминг.
                Performance review наоборот, категорически против этого. Да еще и каждые полгода… Играть одну и ту же пьесу где все реплики и лица наизусть выучены. Процесс выгодный только для высшего менеджмента и до зубной боли надоевший всем остальным.
                  0
                  в рамках этого процесса люди получают обратную связь о своей работе, могут быть уволены, премированы, повышены etc. Каждая встреча и комиссия на этот счёт уникальна, так как ачивки у всех каждый раз новые, а оценка производится с учётом актуального грейда. Что джуниору подвиг, то для senior утро понедельника.
                  Раньше делали вообще раз в квартал, но за такой краткий срок можно не успеть как следует проявить себя.
                  Не могу сказать, что процесс «вспомнить все достижение за полгода и рассказать почему я молодец» вызывает энтузиазм, тут есть свои шероховатости, но с тем, что вы описываете, к счастью, наш процесс ревью ничего общего не имеет.
                    0
                    Уверен, что с субъективной точки зрения тимлида, процесс перфоманс ревью безусловно важен и несомненно полезен. С объективной точки зрения, возможно стоит провести анонимный опрос в компании, результаты вас непременно удивят.
                    После того как такой опрос провели у нас, начался процесс сдвига к team review нежели персонально. Персонально есть 1:1 каждые две недели и тим лид решает вопросы индивидуального перфоманса так сказать пока «железо горячо», чем потом вспоминать за полгода что же было…
                  0
                  Ещё одна проблема всяких ревью — различные точки зрения, на казалось бы простые и очевидные вещи.
                  Реальный пример из личного опыта. Работал я в одной компании, где у нас была ощутимая премиальная часть зависящая от выполнения коммерческих задач. Поясню, коммерческая задача, это такая задача, которую мы делаем для какого-то клиента и клиент этот заплатит за неё деньги. Всё остальное никак на премию не влияет и тем не менее всего остального тоже хватает. Коммерческих задач в разное время могло быть от 20 до 70%.
                  И вот на одном таком перформанс ревью я заявляю, что меня демотивирует то, что я никак не могу повлиять на размер своей премии. Напомню, что премия составляла существенную часть дохода. Удивлению человека напротив не было предела: как так то?! Ты же выполняешь задачи, получаешь за них премии, всё зависит от тебя и только от тебя! После этого был мой черёд удивляться: но я же не выбираю себе задачи! В прошлом месяце я получили премию ого-го, а в позапрошлом ни го-го. Но я одинаково работал оба месяца! Дадут мне много коммерческих задач, премия будет большой, дадут мало — маленькой. Ничегошеньки от меня не зависит. — Но это же ты выполняешь эти задачи, если выполнишь не вовремя или не качественно, премия тю-тю, значит от тебя всё зависит…
                  В общем всё равно каждый остался при своём. И я уверен, что они до сих пор считают эту систему эффективной и супер мотивирующей. А тогда мне это казалось просто лицемерием.

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

                  Самое читаемое