• Teamlead Conf 2019 Msk: про ещё один формат общения
    +2
    Всё в этом мире относительно. Вот тут youtu.be/HRQ73xZuIZQ Олег рассказывает немного про денежные потоки вокруг конференции. Реально работает очень много людей, аредна залов, кейтеринг, обеды, трансферы и т.д. Всё это стоит денег. Если покупать по ранней цене, то будет на 10К дешевле.

    Также для сравнения посмотрите стоимость билетов на AgileDays или на Jpoint.
  • Роль тимлида в рекрутинге
    +1
    Если не затруднит, не могли бы вы рассказать, что такое «профильное образование» для фронтэнда?

    Мы верстаков сажаем на реакт, джейквери тоже кое-где используется. Про БД и прочее мы рассказываем на внутренних микромитапах, так что в общем и целом ребята в теме веба, пусть и без деталей.
  • Роль тимлида в рекрутинге
    +1
    а какой с вашей точки зрения должна быть зарплата для стажёра без опыта?
  • Роль тимлида в рекрутинге
    0

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

  • Роль тимлида в рекрутинге
    +1

    Мы взяли по одному на команду и учим. Так что «никто» — спорный тезис. Верстаков в фронтов переучиваем вполне успешно.

  • Оцениваем процессы в команде разработки на основе объективных данных
    0
    Если ТОЛЬКО на основе метрик делаются решения, касающиеся социальной и экономической составляющей исполнителя (например, премия, зарплата, повышение в должности, прочие материальные и нематериальные блага конкретного сотрудника) — однозначно да. Выше неоднократно говорил и скажу ещё раз. Меряются не люди. Меряется процесс.

    Три года назад я читал доклад на тему тёмной стороны метрик. В нём в том числе я говорил о том, то крайне опасно делать выводы исключительно на цифрах и приводил синтетические, но показательные примеры. www.youtube.com/watch?v=89Xn99ZzZoY
  • Оцениваем процессы в команде разработки на основе объективных данных
    +1

    Звучит так, что вас не повезло с руководителем и, возможно, компанией.


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


    И выжимать при этом я никого не хочу, пооому что разбегутся или начнут хачить систему по закону, который коллега привёл ниже.


    Работник вообще ничего не знает про бОльшую часть метрик. Они нужны для калибровки процесса. И комит в код это лишь одна из метрик для оценки!!! процесса!!.. Если у вас в этот конкретный модуль идут комиты сотнями, значит важность тестов возрастает. Если у вас Вася делает следующим комитом откат предыдущего с завидным постоянством — это повод понять, откуда растут ноги. Может ему требования меняют регулярно и надо дать по голове тому, кто требования носит, а может он тупо не может с первого раза прочитать корректно и его надо научить читать правильно. А может от затрахался и ему надо в отпуск.


    Откуда такое маниакальное стремление во всем увидеть желание работодателя выжать все соки??? Инженер без соков больше ошибается и приносит меньше пользы. Если руководит адекватный менеджер, который умеет адекватно читать результаты измерений — все хорошо и все счастливы. А сдуру, как известно, можно сломать что-угодно.

  • Оцениваем процессы в команде разработки на основе объективных данных
    0

    Due date — инструмент планирования. В скраме инструмент планирования — велосити и капасити, что само по себе чистейшей воды метрики. А выход фич из спринта — метрика для ПМ, по ним он ориентируется на завершение проекта. ПМ в код вообще не должен смотреть. Для него важны проектные и процессные метрики, а не инструментальные. Инструментальные метрики важны для того, кто отвечает за разработку, для СТО, например. Точность и адекватность метрик — это сложный процесс, которым надо заниматься постоянно и калибровать, например, в случае, если сильно изменилась команда. Если подходить к процессу с умом, то кучу пользы можно извлечь от измерений. Причём для всех, а не только для кровавого бизнеса.


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

  • Оцениваем процессы в команде разработки на основе объективных данных
    +1
    некоторые — ничто иное как способ давление, способ заставить девелоперов работать больше, быстрее но при этом ещё и без потери качества.


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

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

    Бизнес платит зарплату. Если бизнес идёт плохо, то зарплату в моменте будет нечем платить. И если ты наёмник (мы ведь в массе своей наёмники, да?), то будь любезен исполнять возложенные на тебя обязанности.

    Еще раз повторюсь — метрики применяются для поиска неисправностей и улучшения процессов горздо чаще, чем для поиска способа напрячь кого-то ещё сильнее. В условиях дефицита кадров на рынке — это стрельба по ногам. Надавили — встали и ушли. Благо есть места, где платят и не давят вообще:)
  • Оцениваем процессы в команде разработки на основе объективных данных
    –2
    Хакнут обязательно, если захотят. Но оставленные артефакты можно проверить, например, тимлидом или руководителем разработки и попросить больше так не делать. Метрики — это лишь часть большого процесса.
  • Коммуникации как performance-зона работы тимлида
    0

    Я бы сказал так: очень зависит от команды и периода ее становления. На начальном этапе можно тратить на коммуникации до 100%, а можно 50%. Все очень зависит. Я ориентируюсь по ситуациии в проекте и по ситуации в команде и варьирую процент времени на коммуникации. Бывает так, что команда уже устоялась и работает вместе давно, но в моменте может потребовать снова 100%. А бывают сложные проекты, там и 146% бывает. Среднее в этом вопросе очень стремная характеристика.

  • Теперь я тимлид, но почему мне так плохо? Практические советы
    +2
    Тест Климова крайне общий и как все тесты очень сильно зависит от текущего настроения и положения дел.
  • Теперь я тимлид, но почему мне так плохо? Практические советы
    –1
    Это призыв посмотреть видео:) Это один из тех докладов, которые не хочется полностью пересказывать или расшифровывать
  • Как это — быть тимлидом в Авито?
    +2

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

  • Классный тимлид ответит за сервис
    0

    Спасибо!

  • Классный тимлид ответит за сервис
    +1

    Автостопом по галактике

  • Тимлид — это сержант в IT-подразделении
    0

    Ефрейтор никогда не был командой должностью, даже самой низшей. Может! временно! исполнять роль командира отделения. А так это лишь способ выделить хорошего солдата над плохими… Капрал — командная должность. Ближайший аналог — сержант. Только это.

  • Тимлид — это сержант в IT-подразделении
    +2
    Всё очень зависит от армии той или иной страны. В Канаде, например, капрал равен сержанту в армии РФ. Ефрейтор в РФ вообще не является командным составом (читай «не руководит никем») и выдаётся военнослужащему за заслуги и выслугу лет. Может назначаться командиром отделения или комвзвода на выполнение поручений с временно подчинёнными рядовыми. Что касается армий НАТО (а у них там всё у всех слегка да отличается) аналогию между капралом и ефрейтором придумали для сканвордов, потому что в реальности это не так.
  • Оцениваем разработчика на основе объективных данных
    +1

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

  • Оцениваем разработчика на основе объективных данных
    +1

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


    Баг багу рознь. Баг с прода меряют очень многие. Число зафейденых ревью коммитов также очень частая метрика.

  • Оцениваем разработчика на основе объективных данных
    +2
    Ну т.е. если у вас 100 инженеров, которые пишут кучу кода в день, нет смысла смотерть и считать метрики? «Быстро сделал» без предварительной оценки — субъективная оценка, можно ведь оценивать по схеме «очень быстро сделал»? Такая же история с «Хорошо работает». Если в это «Хорошо работает» после запуска было два десятка коммитов с исправлениями и улучшениями — изначальное «хорошо работает» — это дейтвительно хорошо?

    Цифрами начинают заниматься тогда, когда что-то идёт не так, а оно не так идёт почти всегда. Просто кто-то не верит своим ощущениям и проверяет измерениями, а кто-то верит и в итоге загоняет проект туда, откуда цифрами и измерениями его уже не достать.
  • Оцениваем разработчика на основе объективных данных
    0

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

  • Оцениваем разработчика на основе объективных данных
    0

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

  • Оцениваем разработчика на основе объективных данных
    +1

    Здесь акцент стоит сделать на «целый квартал» и «почти 100%». Для небольших проектов — это и правда часто страшилка из книжек, а для больших — суровая правда жизни.

  • Как тимлиду выжить в масштабируемом скраме и сохранить контроль за качеством кода
    +1

    Не совсем понял суть вопроса. Если говорить про конференции Бунина, то Евгений несколько раз выступал и является членом одного из программных комитетов. Так что вполне себе знаком участникам.

  • Как тимлиду выжить в масштабируемом скраме и сохранить контроль за качеством кода
    +1

    Согласен, но если начать интерпретировать и выравнивать кривые фразы, всегда есть шанс подменить смысл. В любом случае учту на будущее.

  • Технический долг на проекте или выбраться из черной дыры
    0
    1. По опыту в большинстве проектов фиг кто даст выделить время и отдать часть итерации под техдолг. Почему-то считается, что это вообще не проблемы бизнеса. Мы пробовали разные сценарии: парко-хозяйственный день, когда 20% итерации идёт на техдолг (не очень работает), технологические итерации, когда команда между проектами целую итерацию делает только техдолг и инженерные задачи ( реально работает, но крайне непросто убедить бизнес пойти на это). Аджайл в идеальном мире действительно не про это, но в реальном мире часто все идёт именно по пути замены требований по пути. Тоже самое касается внесения новых задач в уже стартанувшую итерацию. Интересен именно нехороший сценарий.
    2. Выходит, что признание долгом долга вещь сугубо субъективная, я верно понял? Т.е. в задах системы живет пачка овнокода, но поскольку она работает и жить не мешает — она признается нормой?
    3. Вспомнилось «highly likely”:))) Документация часто сама является техдолгом, потому как написать-написали, а поддерживать забыли:))

    Про аджайл спорить не буду, до не тот топик.

  • Технический долг на проекте или выбраться из черной дыры
    0

    В п.2 меняющийся, вместо «отменяющийся». Прошу прощения.

  • Технический долг на проекте или выбраться из черной дыры
    0

    Спасибо за материал, тема, безусловно необъятная, и в одну статью не влезет, есть пара вопросов:


    1. Вот вы пишете, что аджайл помогает решать проблему техдолга за счёт итераций и дробления скоупа. Но ведь тот же аджайл допускает изменения по ходу дела в пользу лучшего продукта здесь и сейчас. Как быть в такой ситуации? Ведь изменяющиеся постоянно требования в угоду рынку и есть причина отсутствия чёткой реализации и обилия костылей.
    2. Мне кажется, что часто отменяющийся код хорош тем, что его часто читают разные скорее всего люди. Ведь тот код, который запилили на скорую руку с костылем или без и ушли из него надолго, закопав стюардессу, есть имхо основной источник техдолга и неожиданных эффектов в будущем, наряду с изменяющимися требованиями и нехорошей архитектурой кода, которую почему-то не упомянули. Вы каким-то образом решаете задачу отслеживания долга в таких случаях?
    3. Куда-то подевалась мать всех костылей — плохая архитектура самого приложения и отдельно взятых модулей. Когда любое расширение несёт за собой боль и страдания. Но при этом вы указали документацию и отсутствие комментариев в коде, что само по себе не является маркером технического долга. Не могли бы вы прокомментировать, как предложенные методы помогут решить вопрос плохой архитектуры?

    Спасибо!

  • Бесплатная трансляция конференции об интернете вещей InoThings++
    0
    habrahabr.ru/company/oleg-bunin/blog/347794 — тут есть краткое описание и ссылка на видео
  • О фреймворках
    0
    В массе своей это лишь говорит о том, что не читают и не слушают. Либо читают и слушают, но формат для должного восприятия не тот. Вот и эксперементируют все понемногу. Кому-то и это чтиво принесёт пользу, я надеюсь. Ваше же комментарии точно принесут пользу мне.
  • О фреймворках
    0
    Пожалуйста:) Рад, что понравилось. Про вред глобальных переменных статей много, а переменных при этом меньше не становится. Про структуру программ тоже все знают, но код говорит про обратное. Про фреймворки рассказывали немало, а проблем при этом меньше не стало.

    Про детали: когда вы упрётесь в проблему, что тормозит не тот код, который вы писали, а то, что под ним — тогда вы почувствуете этот минус.
  • Опрос: какая методология используется в вашем проекте или насколько все у нас через это?
    +1
    Скрумбан можно смело добавлять имхо. Я его три конторы подряд пользую.