Семь смертных грехов PMa

Myroslava Zelenska
Sep 7, 2018 · 7 min read

Гордость, Зависть, Обжорство, Похоть, Гнев, Жадность, Лень. Вы узнаете в этом наборе слов либо список семи смертных грехов, либо темы для телевидения в прайм-тайм. Тем не менее, вас, вероятно, учили в детстве, что это ПЛОХО, и такого не нужно делать. Цель этого поста подтвердить то, чему вас учили. В общем, на работе делать такое тоже ПЛОХО.

Гордость

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

Зависть

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

Менеджеры проектов иногда завидуют друг другу, при этом каждый считает, что другие менее квалифицированы или полезны, чем он сам. Да, у другой команды может быть своя командная комната/большая доска/лучшие компьютеры/более интересный продукт… Все неважно. Найдите интересное в том, что у вас есть, работайте над улучшением того, что нужно улучшить, и прекратите завидовать 27-дюймовому двойному монитору вашего соседа.

Зависть может быть очень опасной, особенно в разработке программного обеспечения. Зависть к другим продуктов часто приводит к “ползучести” фичи по продуктам. В таком случае вы должны спросить: «Нужно ли нам это?». Киллер фича любого продукта— простота, но её как раз сложнее всего спроектировать. Кроме того, легко потерять фокус, когда вы постоянно смотрите, что делают другие компании. Представьте, что вы строите башни из Лего. Вы предпочли бы строить одну башню за раз или много башен параллельно? Параллельный подход работает только в том случае, если башни идентичны. В противном случае вы тратите слишком много времени на переключение контекста. Agility — это не полуготовый продукт. И делать что-то одно, но хорошо, все еще недооценивается многими командами.

Обжорство

Менеджер проекта должен управлять ограничениями треугольника управления проектом, которые представляют собой стоимость, время, объем и качество. Если руководитель проекта страдает “Обжорством”, он может выходить за рамки треугольника и разрушать ограничения.
Например, нет ничего приятнее, чем деливери продукта. Когда у вас в продакшне есть рабочий продукт, высок соблазн начать планирование следующей итерации. Какие новые фичи он должен иметь? На что у нас не было времени в реализации первой(предыдущей) версии?
Легко забыть, что код редко релизится в идеальном виде. Затем, когда функции накапливаются с последующими циклами разработки, программисты склонны смешивать ошибки прошлого, приводя к раздутой, хрупкой базе кода, которая слишком запутана, чтобы сней можно было эффективно работать.
Вместо того, чтобы пичкать тарелку за тарелкой новыми функциями, сдерживайте себя. Оцените качество и поддерживаемость своего существующего кода. Сделайте рефакторинг постоянной позицией в вашем бюджете для каждого нового раунда разработки. Клиенты видят только новые функции в каждом релизе, это правда, но в долгосрочной перспективе они будут благодарны вам за то, что вы помоете эту тарелку.

Похоть

Жажда рынка по вашему продукту может принести вам колоссальную прибыль. Но разработчики программного обеспечения часто жаждут совершенства, что может вызвать серьезные проблемы. Но совершенство — это не о программном обеспечении, потому что оно фрактально по своей природе. Вы можете потратить бесконечное количество времени на оптимизацию очень небольшой части всей программы. Чендлер (да, тот самый) в конечном счете потерпел неудачу, потому что они строили продукт, который не просил ни один пользователь. К тому времени, когда версия 1.0 зарелизилась, остальная часть мира уже перешла на облачные и мобильные устройства.
Современные языки программирования имеют тенденцию добавлять новые фичи по мере своего развития. Они накапливаются на слоях (слой за слоем) абстракции, с новыми ключевыми словами и структурами, предназначенными для обеспечения удобочитаемости кода и повторного использования — при том, конечно, условии, что вы нашли время, чтобы научиться правильно их использовать. В то же время дисциплина программирования изменилась с годами. Сегодня у вас есть гигантские модели шаблонов дизайна, и каждые несколько месяцев кто-то придумывает новую методологию разработки, которая (честное слово!) превратит вас в боженьку среди программистов.

Но то, что хорошо выглядит на бумаге, не всегда работает на практике, и только потому, что вы можете что-то сделать, это не значит, что вам нужно это делать. Как говорит Джоэл Спольский, «деливери (имеется ввиду именно релиз) — это фича. Действительно важная фича. Ваш продукт обязан её иметь». Программисты, которые фетишизируют свои инструменты, неизбежно теряют это из виду, и даже, казалось бы, простейший из проектов может погрязнуть в вечном аду разработки. Сдерживайте свои базовые импульсы и придерживайтесь того, что просто работает и выполняет свою основную цель.

Гнев

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

Жадность

Руководитель проекта — это лицо, ответственное за достижение целей проекта. Неэффективность управления ресурсами очевидна для всех. Вы хотите, чтобы все ресурсы были доступны и всегда в вашем распоряжении в случае появления новых проектов. Вы знаете, что это наверняка плохо, что их навыки необходимы в других местах. На самом деле, иногда вы даже замечаете, что у ваших ресурсов слишком много работы, и ничего с этим не делаете.
Когда заинтересованные стороны или владелец продукта (РО) начнут видеть продуктивные, надежные результаты работы команды и учитывать её скорость (velocity), может возникнуть соблазн попросить команду сделать больше, чем показывают ее реальные достижения. «Разве ты не можешь просто втиснуть в спринт еще пару часов/стори поинтов?» Это должно пресекаться, потому что такие разрешения могут привести к тому, что люди будут меньше времени уделять качеству, срезать edge cases или даже хитрить, ложно раздувая оценки. Доверьтесь команде, пусть она выполняет работу на профессиональном уровне и использует свою реальную скорость для того, для чего она нужна: предсказуемого планирования фич и прочих задач к времени выпуска.
Проблема еще заключается и в том, что жадность часто приводит к краткосрочным целям, что приводит к технической задолженности и в перспективе — медлительности. Чем больше фич мы втискиваем в релиз, тем сложнее поддерживать весь продукт. Особенно с крупными клиентами, легко прогнуться и “быстренько” реализовать одну-две фичи на скорую руку, да еще недопокрыв их тестами, что может негативно отразиться на долгосрочной перспективе. Если ваш крупный клиент решит уйти, с чем вы останетесь? Подумайте стратегически и помните, что ваши клиенты оценят стабильный и качественный продукт — они редко ожидают подобного.
Жадность как чрезмерное стремление к богатству и власти — как еще объяснить мотивы программистов, которые конкурируют со своими коллегами? Один из главных приоритетов управления проектом должен состоять в том, чтобы убедиться, что правая рука знает, что делает левая, и что все команды работают над достижением общей цели.

Лень

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

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade