«Не паникуй, разруливай всё четко по книжке». Как стать крутым Project Manager

Про жизненно важные навыки, инструменты и привычки Project Manager рассказывает Денис Сыраешко, Deputy Delivery Director в Intetics.

Продолжаем цикл про ИТ-специальности. Каждую из них описывает «типичный представитель» — опытный специалист. Мы надеемся, материалы помогут школьникам, студентам, переквалификантам, джуниорам и сочувствующим выбрать специальность в ИТ, оценить перспективы или просто сверить часы с авторитетным коллегой. Обсуждайте и дополняйте материал в комментариях, чтобы сделать его ещё полезней. 

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

Про жизненно важные навыки, инструменты и привычки Project Manager рассказывает Денис Сыраешко, Deputy Delivery Director в Intetics.

Продолжаем цикл про ИТ-специальности. Каждую из них описывает «типичный представитель» — опытный специалист. Мы надеемся, материалы помогут школьникам, студентам, переквалификантам, джуниорам и сочувствующим выбрать специальность в ИТ, оценить перспективы или просто сверить часы с авторитетным коллегой. Обсуждайте и дополняйте материал в комментариях, чтобы сделать его ещё полезней. 

Project Manager сочетает в себе качества разработчика, тестировщика, бизнес-аналитика и управленца. Он держит баланс: длительность проекта + бюджет + качество + сложность + команда.

Чему нужно научиться молодому специалисту, чтобы стать крутым РМ

1. Уметь анализировать предметную область и прототипировать. Любой проект начинается с преображения задач и желаний заказчика, сформулированных в виде спецификаций или на словах, в динамический прототип. Для прототипирования используй Axure. 

2. Разобраться, как выглядят контракты. Не нужно быть юристом, но важно четко понимать, как будет сформулировано предложение для клиента, как будут учтены финансы, структура команды, процессы, план проекта и всё остальное. 

3. Научиться организовывать процесс. Сейчас наиболее популярные методологии Scrum и Agile.

Пришёл и сразу вводи scrum  — это всегда работает

4. Понять, что такое матрица рисков, как ее использовать. На старте проекта важно продумать процесс управления рисками, сделать матрицу и предусмотреть контрмеры в случае возникновения того или иного риска с учетом приоритетности. 

5. Четко отслеживать рабочие процессы.  РМ должен следить, чтобы процесс разработки шел гладко, чтобы все были на одной волне и стремились к одному результату. И регулярно (по Scrum, например, раз в две недели) демонстрировать результат заказчику, получать фидбек, трансформировать его в задачи и планировать следующую итерацию.

6. Хорошо знать методологию управления проектами. PMBOK и другие методологии менеджмента подскажут, как действовать в той или иной ситуации. На практике часто возникают незапланированные ситуации. Каждый такой случай нужно проанализировать, понять, что произошло, найти причины фейла и устранить его. Решить, какие принять меры, чтобы такого больше не повторялось. 

7. Понимать, как работают команда разработки и команда тестирования. Задача РМ наладить процесс разработки так, чтобы было удобно доставлять инкремент продукта на тестовые сервера, и чтобы он качественно тестировался тестировщиками.

Надо знать, что нужно делать, чтобы держать код в порядке

8. Осознавать важность автоматического и ручного тестирования — и балансировать между ними. Например, если сделать слишком много автоматизированных тестов, то для их поддержки нужен ресурс. Автоматические тестировщики на порядок дешевле, чем «ручные». Чтобы все это грамотно соединить, нужны технические знания. 

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

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

Где поучиться на Project Manager

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

Поэтоому идеально, если РМ обладает и техническим и гуманитарным образованием. Большим плюсом будет опыт в маркетинге. 

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

Я обучаю будущих РМ в университете, и мой принцип обучения построен на полном погружении в реальные проекты. Делаю ставку на работу в команде. В ней назначаю роли: девелоперов, тестировщиков, Scrum-мастера, бизнес-аналитика, дизайнера и прочих специалистов. Это полная симуляция проекта. Такой формат даёт очень четкое понимание процессов. 

3 важных совета начинающему Project Manager

  1. Не тушуйся. Ты молодой и тебе нужно завоевывать авторитет среди своих коллег. Пусть твои коллеги старше, это не повод пасовать. Завоевывай авторитет, всесторонне охватывая проект и погружаясь в него. 
  2. Не теряй мотивацию. Когда ты становишься РМ, иногда может казаться, что ты ничего материального не делаешь. Разработчик разрабатывает, тестировщик тестирует, а ты — сидишь в Jira, общаешься с заказчиком… Но твоя польза сразу станет очевидной, когда возникнет стрессовая ситуация на проекте — и ты с ней справишься. Либо когда подведешь итоги проекта. Поэтому на первом этапе просто делай всё по методологии и знай, что ты делаешь правильно. 
  3. Не бойся. Все сценарии описаны в книжках типа PMBOK. И если ты знаешь теорию, то ты ее можешь использовать в непредсказуемой ситуации. Главное — не паникуй, а разруливай всё четко по книжке. И всё получится :)
Кто такой DevOps. Обзор изнутри от Виктора Ведмича
Кто такой DevOps. Обзор изнутри от Виктора Ведмича
По теме
Кто такой DevOps. Обзор изнутри от Виктора Ведмича
Кто такой Project Manager в геймдеве. Обзор изнутри от Ольги Савельевой
Кто такой Project Manager в геймдеве. Обзор изнутри от Ольги Савельевой
По теме
Кто такой Project Manager в геймдеве. Обзор изнутри от Ольги Савельевой
Кто такой нарративный дизайнер. Обзор изнутри от Олега Синицына
Кто такой нарративный дизайнер. Обзор изнутри от Олега Синицына
По теме
Кто такой нарративный дизайнер. Обзор изнутри от Олега Синицына

Хотите сообщить важную новость?

Пишите в наш Телеграм

Читайте также

55% скидка на курс для Project Manager
55% скидка на курс для Project Manager
55% скидка на курс для Project Manager
2 октября начинается онлайн-курс для тех, кто хочет научиться балансировать ресурсы: время, деньги, занятость команды, а также качество, риски и другие параметры для достижения четких результатов в установленные сроки.
Кто такой Performance Engineer? Обзор изнутри от Вадима Волкова
Кто такой Performance Engineer? Обзор изнутри от Вадима Волкова
Кто такой Performance Engineer? Обзор изнутри от Вадима Волкова
Про профессию рассказывает Вадим Волков из EPAM. Продолжаем цикл материалов про ИТ-специальности. Каждую описывает «типичный представитель» — опытный специалист и просто авторитетный коллега, тот самый человек, который знает все тайные уголки своей профессии. Мы надеемся, эти материалы помогут школьникам, студентам, переквалификантам, джуниорам и всем тем, кто заинтересован в выборе ИТ-специальности. Цикл не только поможет оценить перспективы, но и даст возможность лучше понять индустрию и особенности профессии изнутри. Обсуждайте и дополняйте материал в комментариях, чтобы сделать его еще полезней.
3 комментария
Кто такой бизнес-аналитик. Обзор изнутри от Ксении Лаце
Кто такой бизнес-аналитик. Обзор изнутри от Ксении Лаце
Кто такой бизнес-аналитик. Обзор изнутри от Ксении Лаце
Про профессию рассказывает Ксения Лаце, ведущий бизнес-аналитик в компании Evolution Gaming.  Продолжаем цикл материалов про ИТ-специальности. Каждую из них описывает «типичный представитель» — опытный специалист и просто авторитетный коллега, тот самый человек, который знает все тайные уголки своей профессии. Мы надеемся, эти материалы помогут школьникам, студентам, переквалификантам, джуниорам и всем тем, кто заинтересован в выборе ИТ-специальности. Данный цикл статей не только поможет оценить перспективы, но и даст возможность лучше понять индустрию и особенности профессии изнутри. Обсуждайте и дополняйте материал в комментариях, чтобы сделать его еще полезней.
5 комментариев
Кто такой геймдизайнер. Обзор изнутри от Алексея Кожарского
Кто такой геймдизайнер. Обзор изнутри от Алексея Кожарского
Кто такой геймдизайнер. Обзор изнутри от Алексея Кожарского
Про профессию рассказывает Алексей Кожарский, лид геймдизайнер в Awem Games. Разрабатывал дизайн уровней Match-3 в Cradle of Rome, Cradle of Egypt, а также портировал эти игры на мобильные устройства. В настоящее время работает с продуктом Cradle Of Empires.  Продолжаем цикл материалов про ИТ-специальности. Каждую из них описывает «типичный представитель» — опытный специалист. Мы надеемся, что цикл поможет школьникам, студентам, переквалификантам, джуниорам и сочувствующим выбрать специальность в ИТ, оценить свои перспективы или просто сверить часы с авторитетным коллегой. Можно обсуждать и дополнять материал в комментариях, чтобы сделать его ещё полезней. 
1 комментарий

Обсуждение

0

Цитирую книжку и много . Спасибо вам ментор ) за статью p.s: U.S embassy its once again for you and O1 purpose . Not for us as community. Cheers.

Anonymous
Anonymous
5

Там нужны нормальные публикации на O1, а не интернет статейки всякой херни на мутном локальном портале.

3

Если хабр вполне закатывает , то почему локальный девбай не то ?)

4

Почему вы каждый раз это пишите? Это ведь не разовая статья, это цикл девбая про разные профессии. Причем здесь эта виза?

1

А какое информационный меседж несут эти статьи про почитай книжку или прошлая про джиру месседжер как основные инструменты менеджера ? Нет серьезно таких людей все ещё держат ???

Anonymous
Anonymous
35

"Пришёл и сразу вводи scrum — это всегда работает" – Я даже не знаю что сказать. Хотел много чего сказать, но не буду. С каждым днём вокруг становится все больше странных людей. Менеджеров, со скрам сертификатми, которые приносят скрам куда угодно, а сути работы не понимают, аджайл коучей продающих сертификаты, разработчиков, которые просто делают работу чтоб зарыть таск, энтерпрайз заказчиков не понимающих зачем вообще им нужен апп и как и кто потом будет его использовать. Все это давно превратилось в клоунаду. Куда бы свалить, чтоб не видеть всей этой заказной разработки, клоунов и тотальный пофигизм и "командную работу" с тимблидингами и ретроспективы, где обсуждают ощущения от спринта и творится какой-то детский сад. Где-то ещё остался профессионализм?

5

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

5

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

Anonymous
Anonymous
4

Добавлю ещё три больших недостатка, при формальной организации:

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

3

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

Сдается мне, опытный разраб должен быть способен адаптироваться к контексту конкретного проекта, а не саботировать работу, если контекст для него неидеален. Опыт штука такая, календарная.. Зрелый, скажем так.

1

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

0

Ваш отжайл про гибкость и адаптацию..зачем же слово правильность ? Или развернем на проект в два месяца отжайл на фиксед прайс ?

1

"Хорошо работающий" Scrum описан в The Scream Guide.

3

+1. Сколько скрам-гайд ни читал, он и в подметки не годится The Scream Guide по близости к реальной жизни.

-8

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

15

Совет номер 0. Думайте своей головой, критически анализируйте все статьи и книжки, все модные тенденции - как и почему они работают. Есть такие понятия как «карго культ», “process junkie”, «микроменеждмент» - к ним может привести буквальное следование советам автора статьи. Управление - это прежде всего опыт, набитые шишки, умение думать и устанавливать хорошие отношения, книги помогут, но они вторичны. ИМХО. Почитайте хорошую литературу - Достоевского, Стейнбека, Д.Элиота. Помимо фана, они помогают развить умение понимать других людей.

-4

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

3

Я не знал, что мой комментарий может привести к такому выводу, поэтому поясню.
психологи бывают разные и они далеко не всегда пример того, чему они учат (сапожник без ботинок)

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

-2

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

-3

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

19

работала под начальством героя статьи и очень сомневаюсь в его "крутости")

-11

А поподробнее ?? Для посольства важна информация в выдаче визы по одаренной линии О1

Что ты как попугай со своим O1? Может он сразу на ЕВ1 тебе то что?

0

Мисье , зачем вам вообще ит портал , если водить в зоопарке можно и так ...

Anonymous
Anonymous
4

сказав А, стоит сказать Б

-6

авторитетный отзыв от девочки с курсов :)

-2

Ваша профессиональная неэтичность заставляет сомневаться в Вашей "крутости" :)

16

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

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

что здесь хотел сказать автор - не понятно.

9

Зато он продемонстрировал менеджерскую хватку: пока знатоки молчали, он взял и выдал что умел. Парадокс Даннинга-Крюгера.

5

Не ругайте пианиста, он играет, как может

-9

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

15

Ох уж эти мамкины руководители.

Agile, книги, цитаты и т.д.

-7

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

14

Типичный вредитель. Зачем их только нанимают, умом понять сложно.

-9

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

1

Мисье код писал в своей жизни ?

9

"3. Научиться организовывать процесс. Сейчас наиболее популярные методологии Scrum и Agile.
Пришёл и сразу вводи scrum — это всегда работает"

у скрама есть огромные минусы, для этого надо писать еще одну статью.

"Делаю ставку на работу в команде. В ней назначаю роли: девелоперов, тестировщиков, Scrum-мастера"
Внутри Девелопмент Тим есть только одна роль — developer. Других должностей, ролей, под-команд — нет, иначе это уже не скрам.

Про управление рисками он правильно написал. Но те ляпы что написаны выше.......

Скажите, как с такой дикцией вы попали на ТВ? Блат?
Нет. Систла. ;)

Аффтор, я сертифицированный менеджер.
Могу тебе по блату писать норм. статейки, с которых не будут ржать.
Цена $1K за шт, зато будет качество, + на 2 языках сразу, сможешь засветиться и на англоязычных бордах.

-7

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

0

Уже открыло посольство ? После снятия ковид ограничений вылетаете в NY ?

4

"
...
«А мы самые крутые!» Впереди себя несем свои пальцы. Но не знали мы молодые, Что крутыми бывают лишь яйца.
...
"

...А заметка - очень слабенькая.

5

Помощник директора доставки?

3

Есть дельные советы, конечно, но такое ощущение, словно человек знаком с процессами/практиками только по работе в одной компании. Ну и разницу между методологией и фреймворком надо все-таки понимать.
С другой стороны, деливерит, судя по должности, вполне успешно. Хорошая иллюстрация к заблуждению «зеленого леса», про которое писал Талеб в Антихрупкости )

-6

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

14

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

-6

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

7

Не понимаете. И судя по дальнейшему тексту и не хотите понимать.
Это совет джуниору менджеру, как не стать г..манагером ой, в смысле карго-культ-манагером.

1

На самом деле прямое, оно в общем то раскрывается в фразе: "Пришёл и сразу вводи scrum — это всегда работает".

3

Правильно начинать Срам-ритуал с вопроса - у кого какие вопросы или проблемы. Если есть человек, который обычно тихорит проблемы- вот у него и можно спросить, чем он там сегодня занимался и все ли получается. Но, мать его Agile, не каждого подряд! )))

0

Изначально стэндапы предназначены для решения затыков, а не отнюдь для пытки :) Есть вариант даже не спрашивать никого в команде, а элементарно смотреть прогресс по трекинг системе и коммитам. Но более приятен душевный вариант развития событий, когда в команде не просто формальное общение, а ещё и понимание и дружественная атмосфера, в которой приятно работать, Но это отдельная тема для размышлений :)

2

Вот и рассказывайте в первую очередь про этот вариант, а то создается впечатление что он секретный и не всем молодым срам-подмастерьям про него рассказывают )))
Приятную амосферу не создашь по расписанию на 15 минут. Она возникает случайно. Незапланированно )

0

Принято. Возможно, редакторы преобразовали статью в тонусный формат, чтобы не расслабляться. Порой надо четко и по пунктам, а потом душа.
Надеюсь, не смотря ни на что, нам с Вами удалось создать эту самую приятную атмосферу ;)

2

Всегда интересно читать комментарии. Материал подготовлен для школьников и студентов. Денис Сыраешко ведет курс для студентов БГУ более 4 лет и делится экспертизой на разных уровнях. Работаем вместе, особенно в части менторства. Если есть предложения для талантливых школьников и студентов, присоединяйтесь :) проектам всегда нужны менторы/эксперты и поддержка.

5

О, уже проджект менеджеров набирают прямо со школьной скамьи?
Хотя, почему нет: "Пришёл и сразу вводи scrum — это всегда работает" (с)

13

Молодых специалистов надо учить как НЕ скатиться в PM. Туда они всегда успеют, а вот назад возвращаются только единицы.

-3

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

6

К слову сказать, в современных фреймворках таких как Scrum, который и автор статьи упоминает, никакой роли ПМ нет и не будет уже никогда. По сути роль ПМ это атавизм, паразитирующий на проекте который как правило только вредит т.к. основная цель его - оправдать свое существование, за редкими исключениями. Поэтому переход "специалист -> PM" происходит в основном в случае когда специалист слабый и не любит свое дело.

-5

Интересное и популярное мнение участника высоко самоорганизованной команды. Рад, что на Вашем проекте все административные задачи решает коллективный разум.

3

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

Vitali Karpovich
Vitali Karpovich Business consultant в Biclast solutions
2

Скрам и отсутствие PM'а оправдано в маленьких проектах где между собой могут договорится 5-10 человек. Совсем другая ситуация когда в проекте участвуют сотни и тысячи людей. И тут роли PM'ов -> контролировать и управлять не не только сроками/бюджетами/рисками, но и устранять преграды, находить компромиссы для результативной работы людей.

-2

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

3

Менеджер-недоучка не может и не должен решать что нужно команде, ему бы хорошо найти свое место в жизни.

2

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

0

Я ещё немного запутался в этих никах user...... :) Было бы прекрасно, если бы Вы решились указать своё имя. Хотя Ваша позиция уже и так понятна. Спасибо.

0

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

1

Это и называется Срам-процесс )))

2

Sad but true.

-3

Интересное и популярное мнение участника высоко самоорганизованной команды. Рад, что на Вашем проекте все административные задачи решает коллективный разум.
*Удаление постов здесь не возможно. Извиняюсь. Целился в другую подветку беседы.

Anonymous
Anonymous
10

Итак, что я хочу как инженер. Да в сервисные/аутсорсные компании не ногой, это просто отстойник, но все равно, напишу:

1 Отвественность за свой результат от начала до выкатки, не командую ответственность, не ответственность на дейлике. А настоящую ответственность за результат.
2 Разговаривать непорседственно с людьми, для кого я это делаю, видеть статистику по пользовательским данным, непосредственно разговаривать с продуктовым менеджером, в случае что он есть.
3 Письменная и асинхронная коммункация. Я хочу синхронизироваться с другими людьми, когда мне это будет нужно, или отвечать, когда кому-то из них от меня что-нибудь нужно пару раз двень, чтоб меня никто не дергал.
4 Удаленная и распределённая команда. Как правило, работать в распределённой команде на продукте гораздо приятнее, и там взрослые независимые люди.
5 Требования по качеству, перформансу, хорошо настроенный разработчиками CI/CD.
6 Тесты - разработчики должны сами писать интеграционные тесты, после того как они написали функционал. И менять архитектуру, а не просто делать юзер стори, расчитывая максимум втиснутся спринт.
7 Архитектурные пропузалы - если кто-то хочет сделать крупное архитектурное изменение, он должен написать пропоузал на ревью остальными членами команды. Через пул реквест в маркдауне, что вызовет пиьсменное обсуждение, результаты которого останутся а документ дополнится.
8 Open allocaiton в рамках беклога приоритетов.
9 Приоритеты должны быть обоснованны, желательно анализом пользовательских данных, голосованием пользователей по фичам etc...

Чего я не хочу:

1 Командных итераций и зависимости
2 Каждодневных отчётов
3 Дробления на мелкие таски и микроменеджмента
4 Проектного менеджера - давно их не видел, только в аутсорсе и только в СНГ. У нас есть: продукт оунер, он исключительно бизнес чувак. Engineering manager - people manager для программистов, не говорит как тебе работать и что делать, только помогает с организацией и говорит что не так, помогает на 1-1 с сомнениями и идеями: но я вообще открытый чувак, не стесняюсь написать о своих сомнениях в специальный канал слака сразу всем, кто захочет прочитать и обсудить. Сам может в технические спеки и архитектуру. Он не выше тебя по значению на проекте. Один менеджер на 10 человек видишь его не часто, а когда нужно.
5 Детсадовских командных ретроспектив. Не нравится что-то в каком-то аспекте, напиши в слак предложение как улучшить. Обсудите с ребятами этот момент. Вы не в детском саду, вас не надо садить в кружок и спрашивать, а что не понравилось. А если из вас надо вытягивать, то вы сами виноваты. Будете несамостоятельным и команда вас уволит..

Anonymous
Anonymous
1

Какой у нас прцоесс? Kanban - здорово визуализирует кто чем занимается, помогает тебе WIP лимитами. Да и по cycle time видно где затыки и нужна помощь, но люди как правило осознанные и сами все организовывают, обращаются за помощью, спрашивают. Можно делать пару вещей отдельно, т.к надо свичится на что-то другое в случае затыка или когда ждешь ответа по какому-либо вопросу.

0

Вообще нечего возразить, на удивление. Четко и по делу сказно. Поставил Вам лайк. Это немного не по адресу статьи. Однако спасибо, что решили это опубликовать именно на этой странице :)

Anonymous
Anonymous
0

Это как ответ на вашу фразу: "Пришёл и сразу вводи scrum — это всегда работает".

1

Я уже немного комментировал по этому поводу выше. Не знаю, почему редакторы решили выделить эту фразу, но акцента на Scrum не планировалось. Уже сделал для себя вывод, что именно Scrum цепляет, поэтому учтем этот маркер при публичных рассуждениях. Команда сама выбирает для себя удобный способ двигаться вперёд с учётом предпочтений заказчика и политики компании. Спасибо за критику.

0

В целом годно, пара замечаний:
1 и 8 противоречат друг другу: если вводить ответственность, то должна быть и зона ответственности. Если один кусок будет писаться по принципу open allocation то и ответственность размывается. Обе фичи написаны хорошо, вместе - работают плохо, чем сложнее функционал, тем меньше надежды на интеграционные тесты.
7 задвинуть архитектурные ченджи на обсуждение - это хорошо. Но, оно опять же противоречит пункту 1. Кто будет отвечать, если чендж приведет к убыткам? Архитектурные ченджи на этапе реализации - это само по себе серьезный просчет, за который кто то должен ответить.

0

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

Anonymous
Anonymous
2

1-8. Ты освободился и решил, ага я буду дальше делать вот эту вещь. После этого ты несешь за неё ответственность:
1 общаешься с продукт оунером, чтоб разобраться что нужно и зачем, для кого, почему. Вносишь свои предложения.
2 Если надо что-то выбросить и изменить в текущем коде и что-то уже не вписывается, выбрасываешь и переделываешь без страха.
3 Убеждаешься, что собирается статистика, мониторинг, логируется что нужно, прикидываешь нагрузку и пишешь деплойменты для куба с лимитами на ресурсы.
4 Обазяательный код ревью: выбираешь тех, кто комитил в эти куски больше всего
5 Тесты, если какие-то две фичи плохо работают вместе, это недостаток тестов. Интеграционные тесты можно разделять на различные пакеты, и не обязательно тестировать все со всем, а то что связано по смыслу. Этот микросервис виляет на то, то и то. Так и тестируй функциональность с тем и тем и пиши такие интеграционные тесты. Да будет куча проблем, но все поправимо, если этим заниматься и следить за тестами.

7 Не надо бояться выбрасывать код когда он становится большой проблемой и перестает отвечать текущим потребностям и изменения становится вносить больно. Почему-то считается, что что-то переписывать это провал, но бестрашный выброс кода - это наиболее прямолинейный путь, особенно если продукту уже 5 и более лет. Очень грустно, если вы работаете в жадной компании, и вам приходится срезать углы в крупных и проблемных вещах.

1

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

Anonymous
Anonymous
2

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

3

Как-то у меня эти советы отторжение вызывают
Попробую обрисовать

Не тушуйся. Ты молодой и тебе нужно завоевывать авторитет среди своих коллег. Пусть твои коллеги старше, это не повод пасовать. Завоевывай авторитет, всесторонне охватывая проект и погружаясь в него.

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

Не теряй мотивацию. Когда ты становишься РМ, иногда может казаться, что ты ничего материального не делаешь. Разработчик разрабатывает, тестировщик тестирует, а ты — сидишь в Jira, общаешься с заказчиком… Но твоя польза сразу станет очевидной, когда возникнет стрессовая ситуация на проекте — и ты с ней справишься. Либо когда подведешь итоги проекта. Поэтому на первом этапе просто делай всё по методологии и знай, что ты делаешь правильно.

А может, показатель твоего успеха - это как раз такое состояние проекта, когда окружающим непонятно, что ты делаешь и где вообще твои усилия и их результаты? Это ведь отсутствие проблем, пониженный показатель "количество телодвижений менеджера на написанную строчку кода". Конечно, потушенный пожар выглядит эффектнее и так ты будешь больше похож на героя боевика, но это не более чем прокачка своей самооценки. Лучше когда пожаров вообще нету.

Не бойся. Все сценарии описаны в книжках типа PMBOK. И если ты знаешь теорию, то ты ее можешь использовать в непредсказуемой ситуации. Главное — не паникуй, а разруливай всё четко по книжке. И всё получится :)

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

Вобщем, это всё попахивает каким-то незрелым дартаньянством. Моё личное ощущение

4

Но твоя польза сразу станет очевидной, когда возникнет стрессовая ситуация на проекте — и ты с ней справишься.

А не могли бы вы рассказать 2-3 кейса как вы мастерски справились со стрессовой ситуацией на проекте?

К сожалению, то, что написано в статье про Scrum, является некорректным:

1 Не верно, что Scrum всегда работает. Это инструмент и надо понимать, когда он нужен, а когда - нет. И уж тем более нельзя заставлять людей использовать Scrum (заставлять вообще плохо).

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

3 Ирония в том, что в правильном Scrum такая роль как Project Manager скорее всего становится не нужной.

Максим Баталин
Максим Баталин RTE в ArasCorp Development Center
1

Константин, с языка сорвал :)

0

К Константину стоит на тренинг сходить - он плохого не посоветует!

Максим Баталин
Максим Баталин RTE в ArasCorp Development Center
4

Когда ж уже перестанут Скрам и Аджайл называть методологией? Не мешало бы и автору разобраться в этом вопросе перед публикацией статьи хотяб вдумчиво прочитать разок скрам гайд:
“Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques.”

2

"Никогда не трогай работающую технику/команду/сервер/etc и она тебя не подведет".
Заруби на носу, сынок.

("Пришёл и сразу вводи scrum")

Anonymous
Anonymous
0

Только хардкор что-ли? Только Кобол!

Anonymous
Anonymous
0

Если сервис на коболе не приносит проблем, так и не трогай. Когда начнутся, тогда и переделаешь.

Спасибо! 

Получать рассылки dev.by про белорусское ИТ

Что-то пошло не так. Попробуйте позже