Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть

PM дайджест #14: советы по подбору персонала от Netflix, совмещение ролей тимлида и ПМа, переосмысливаем Scrum

Всем привет! Делюсь очередной порцией интересных материалов по управлению проектами в первом осеннем выпуске PM дайджеста!

Project Management

No comments: The 12 signs how to know when you’re slowly but surely becoming a bad manager

Великолепная статья/слайдкаст доклада о том, как измерять эффективность разработчиков. Must Read.

Нам нужны не менеджеры, а Servant Leaders! :) А если серьезно и без buzz-words, то советы из статьи очень толковые и обязательные к исполнению для хорошего менеджера в 2018 году.

Chief Talent Officer горячо любимой нами компании Netflix в деталях делится своим опытом и подходами к подбору новых сотрудников.

Top quote:

Making great hires is about recognizing great matches.

Две статьи о Code Review:

Я не согласен с одним из посылов второй статьи, что Code Review — это инструмент обучения, просто потому, что обучение через Code Review удлиняет процесс delivery до недопустимых для бизнеса показателей. Это инструмент проверки качества и только его. Но если вы как ПМ не настроили себе как минимум нотификации о пулл-реквестах (а лучше сразу батчи, как рассказывает автор), то только супер-расторопный тимлид поможет вам совладать с вашей командой :)

Еще одна статья об утопичности совмещения ролей тимлида и project manager’a. Классная цитата:

Management is highly interruptive, and great engineering — where you’re learning things — requires blocking out interruptions. You can’t do these two opposite things at once. As a manager, it is your job to be available for your team, to be interrupted.

Если вы хотите настоящей производительности от своих команд (а не мнимого чувства контроля над ситуацией) — избавляйтесь от open space’ов и переходите в небольшие комнатки.

Продолжая тему организации рабочего процесса в компании в целом — помечтаем. Мы не в Новой Зеландии и не в Скандинавии, чтобы обсуждать подобного рода инициативы, но есть мнение, что 3х-дневный уикенд действительно может полезно сказаться на производительности разработчиков и всех причастных — работников интеллектуального труда :)

How to fail as a new Engineering Manager

История о том, каково это быть тимлидом в маленьком аутсорсе в 2018 году. Внутри Битрикс и прочий 1C, но люди-то особо не варьируются.

Agile, Scrum и все такое

Великолепная статья Рона Джеффриса о том, когда скрам помогает командам становиться лучше, а когда — все портит. Спойлер: сам по себе скрам ничего не портит :)

Статья от Engineering Lead’a компании Spotify с призывом прекращать проводить регулярные стендапы, планирования и ретро.

Советы от Юры Козия о том, как добиться эффективности и результативности на ваших (не обязательно регулярных) митингах с помощью фасилитации.

Причины, которые приводят к неправильному восприятию ретроспектив командой и советы по исправлению ситуации.

The state of Agile Softawre in 2018 — транскрипт доклада Мартина Фаулера.

Fun

Наверное, этот твит должен был быть в другом дайджесте, но я не сдержался: у команды всегда должен быть план Б!

Д — делегирование

Разработка проекта (плота)

Перефразируем так: ПМ на митинге с техлидом и девелопером на стороне заказчика.

Испанец об установке на продакшен. Управление проектами. Аджайл. Скрам.

Жиза


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


← Предыдущий выпуск: PM дайджест #13.
Следующий выпуск: PM дайджест #15

LinkedIn

10 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.
Management is highly interruptive, and great engineering — where you’re learning things — requires blocking out interruptions. You can’t do these two opposite things at once. As a manager, it is your job to be available for your team, to be interrupted.

Классная цитата и подборка в целом.

Я не согласен с одним из посылов второй статьи, что Code Review — это инструмент обучения, просто потому, что обучение через Code Review удлиняет процесс delivery до недопустимых для бизнеса показателей.

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

удлиняет процесс delivery до недопустимых для бизнеса показателей

Вот тут интересно было бы услышать числа. И сравнить их с теми затратами которые возникают при применении альтернативных методов.

Это инструмент проверки качества и только его.

Только в том случае если у вас в комманда состоит из джунов и говнокодеров, тогда 1-2 адекватных синьора могут «улучшить» качество, но более правильно будет сказать что не допустить настолько низкого уровня, что проект не вытянуть даже 100% овертаймами.
В остальных случаях, процент багов пойманых на код-ревью будет минимальным и, как правило, это будут механические ошибки. ... Или баги связанные с тем что исполнитель не знал чего-то о системе (тут мы возвращаемся к «обучению»)

P.S. Я ссылки не читал, если ответы на мои вопросы есть по ссылкам, то бросьте пожалуйста по какой ссылке надо сходить.

Богдан, спасибо за коммент. Ответы на все ваши вопросы есть в статейке:
habr.com/...​ompany/badoo/blog/413965
Она упоминалась в прошлом dou-digest’e, и сейчас для меня лично (ведь в колонке я пишу исключительно свое ИМХО) является Ultimate How-to on Code Reviews, в первую очередь из-за текущих челленжей на проекте и необходимостью глубоко лезть в детали — прояснять корневые цели процесса код-ревью, чтобы избежать очевидного деливери боттл-нека, когда задачи днями лежат в этой колонке.

Я не согласен с одним из посылов второй статьи, что Code Review — это инструмент обучения

Code Review — це як раз дуже сильний інструмент навчання.

Я считаю, что это в первую очередь это этап процесса разработки, а именно — проверки качества. Инструмент обучения — как очень побочный эффект, на случай если в процессе верификации реализации на корректность, соответствие архитектуре и следование установленным в команде практикам удалось что-то для себя вынести. Если в команде, ответом на вопрос, «зачем код ревью?» отвечают: «для обучения», есть подозрение, что скорость доставки задач этой команды можно сильно оптимизировать

Звичайно, первинна роль — це перевірка якості кода та пошук помилок. Навчання йде бонусом до всього цього.
P.S. Не знаю жодного проекта, який зафейлився тому, що було багато рев’ю кода.

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

habr.com/...​ompany/badoo/blog/413965

:)

позалипать в чужой код

Девелопери ненавидять чужий код! Тому залипати ніхто не буде. Можуть бути спірні питання, але на то є тімлід/девлід.

Прошу прощения, но Ваша ссылка ведет на 404 — Страница не найдена. Хотя подобные страницы могут вправлять мозги теоретически, но может Вы существующую статью хотели бросить?

Подписаться на комментарии